however you are setting a drupal_set_header("HTTP/1.1 301 Moved Permanently"); a 302 is executed.

it looks like this is caused by drupal_goto and the location inside this function, but i currently don't know why...

i have tested this with the path.inc v1.4.2.5 (CVS) on Drupal 4.7.4 with your v1.1 and HEAD version with no difference.

This is the Log:

GET /drupal/index.php?q=node/21 HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: de,en;q=0.8,en-us;q=0.6,de-de;q=0.4,es;q=0.2
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: PHPSESSID=8tjb18qeg9fvbd267c1ojahha3

HTTP/1.x 302 Object Moved</strong
Server: Microsoft-IIS/5.1
Date: Tue, 26 Dec 2006 13:15:46 GMT
Connection: close
Content-Type: text/html
X-Powered-By: PHP/5.1.0
Set-Cookie: PHPSESSID=8tjb18qeg9fvbd267c1ojahha3; expires=Thu, 18 Jan 2007 16:49:05 GMT; path=/
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified: Tue, 26 Dec 2006 13:15:45 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Location: http://localhost/drupal/index.php?q=example

Comments

hass’s picture

hass commented

looks like a known bug... http://drupal.org/node/75803 and no backport to 4.7.x

looks like you need to rebuild the drupal_goto function for your own...

hass’s picture

hass commented
Version: 7.x-1.x-dev » 4.7.x-1.x-dev

Change all your drupal_goto into globalredirect_goto. i changed this bug to 4.7, while you are able to whipe out this workaround for Drupal 5 and only change the 4 param for drupal_goto.

function globalredirect_goto($path = '', $query = NULL, $fragment = NULL, $http_response_code = 301) {
  if (isset($_REQUEST['destination'])) {
    extract(parse_url(urldecode($_REQUEST['destination'])));
  }
  else if (isset($_REQUEST['edit']['destination'])) {
    extract(parse_url(urldecode($_REQUEST['edit']['destination'])));
  }

  $url = url($path, $query, $fragment, TRUE);

  // Before the redirect, allow modules to react to the end of the page request.
  module_invoke_all('exit', $url);

  header('Location: '. $url, TRUE, $http_response_code);

  // The "Location" header sends a REDIRECT status code to the http
  // daemon. In some cases this can go wrong, so we make sure none
  // of the code below the drupal_goto() call gets executed when we redirect.
  exit();
}
Anonymous’s picture

Anonymous (not verified) commented

Can you create a patch and attach it? There is talk of a Drupal 4.7.5 release and this could go to a 4.7.5 release for globalredirect.

hass’s picture

hass commented

This looks more a PHP Bug. I verified the Bug with PHP 5.1 and 5.2 with CGI on IIS. I read about such bugs in PHP Bug database, but all cases are closed or marked as bogus.

On Apache the module is working correctly with the updated path.inc. However i found some comments on PHP.net explaining it is not correct to send two headers. First the Status 301 and then the location should be wrong... the following is the correct redirection - i don't know.

header('Location: '. $url, TRUE, $http_response_code);

nicholasthompson’s picture

nicholasthompson
Primary language English
commented

So is it a bug with PHP5/IIS or is this a problem I need to address in the module?

hass’s picture

hass commented

today it looks like a PHP bug... however the bug has been closed on 1.1.06 and i was told it was fixed in CVS, but until now it isn't... however it looks not like a bug in your module.

Asside - as a reminder for Drupal 5 you must remove the header 301 lines and change the goto lines into...

drupal_goto($url, true, 301);

nicholasthompson’s picture

nicholasthompson
Primary language English
commented
Status: Active » Postponed

Will change this - thanks for the heads up!

nicholasthompson’s picture

nicholasthompson
Primary language English
commented
Status: Postponed » Fixed

I updated the code for Drupal 5 and I've checked that 301/302 bug and I don't seem to be getting any problems...

[nthompson@homeserver ~]$ curl -v http://www.thingy-ma-jig.co.uk/node/73
* About to connect() to www.thingy-ma-jig.co.uk port 80
*   Trying 85.234.144.42... connected
* Connected to www.thingy-ma-jig.co.uk (85.234.144.42) port 80
> GET /node/73 HTTP/1.1
> User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8a zlib/1.2.3 libidn/0.6.2
> Host: www.thingy-ma-jig.co.uk
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Date: Thu, 25 Jan 2007 21:44:51 GMT
< Server: Apache/2.0.54 (Fedora)
< X-Powered-By: PHP/5.0.4
< Set-Cookie: PHPSESSID=3l1o92gkdmtscctb8uovpjv166; expires=Sun, 18 Feb 2007 01:18:11 GMT; path=/
< Expires: Sun, 19 Nov 1978 05:00:00 GMT
< Last-Modified: Thu, 25 Jan 2007 21:44:51 GMT
< Cache-Control: no-store, no-cache, must-revalidate
< Cache-Control: post-check=0, pre-check=0
< Pragma: no-cache
< Location: http://www.thingy-ma-jig.co.uk/blog/18-01-2007/xkcd-a-webcomic
< Content-Length: 0
< Content-Type: text/html; charset=utf-8
< Age: 483
< Connection: close
< Via: HTTP/1.1 ntl_site (Traffic-Server/5.2.4-59651 [cMsSf ])
* Closing connection #0

I'm gonna mark this as fixed as I've address the only problem I'm in control of - so it seems :-)

hass’s picture

hass commented

yes, the not correctly set HTTP status code is a IIS-with-PHP bug... for sure, not yours :-).

nicholasthompson’s picture

nicholasthompson
Primary language English
commented

Wow - its so unlike an MS product to have a bug in it ;-)

I've always wondered why people chose to use Windows to run a WebServer...

hass’s picture

hass commented

But it's an PHP Bug on the end of the day... not MS fault :-).

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)