Change History (11)

this sounds to me like WordPress can't determine the folder correctly.. You may want to dump $_SERVER in both wp-config.php and in install.php as $_SERVER may be modified between them. (see wp_fix_server_vars() in wp-includes/load.php - I'm not sure if that's run for Installation however)

Extracted wordpress files to C:\inetpub\wwwroot\wordpress Created a Virtual Directory 'blog' to point to that folder as well

Loaded ​http://localhost/blog/ and was redirected to the folder as expected. My $_SERVER contents looks the same as your's for the most part..

Have you configured something else related to redirects, or Rewrites, or something? I have a feeling something in your server stack is intercepting the redirection and not passing it to the browser, but making the request itself..

Have you configured something else related to redirects, or Rewrites, or something? I have a feeling something in your server stack is intercepting the redirection and not passing it to the browser, but making the request itself..

There is no redirects and no URL rewrite module on this server. The virtual dir is showing as pointing directly to the physical directory.

The IIS on this server has no knowledge of wp-admin\install.php. Only WP has. If I remove install.php there is a 404.

The first thing is that his means that in case the server is IIS the redirect method should be the "Refresh" header. Othwerwise the redirect method should be the "Location" header. This is strange, because the Location header also works on IIS.

The second thing is that the $is_IIS variable is not initialized inside wp-includes/load.php, as this is required from wp-settings.php before the vars.php is requierd. In case the blog is not installed yet, but a wp-config.php is present, the redirection to wp-admin/install.php is done from wp-includes/load.php. This means that the redirect method used for any server is the Location header.

The third thing is that, on my system, when a redirect is done with a relative URL, the redirect is done "internally". This means that the browser will not know that actual resource served to it. But, strangely, the IIS log file shows the actual wp-admin/install.php as being requested. This is very, very strange to me, and I have no explaination. I have no other IIS6 systems to etst this on.

The fourth thing, and this is the main reason (and bug?), is that WP_SITEURL is not defined in wp-includes/load.php, as long as it's not defined in wp-config.php. This means that the redirection location will miss the site part and be relative. Combined with the undefined $is_IIS the redirect will fail. From load.php:

Remove the "Refresh" redirection method from wp_redirect, as I cannot see the need for this, and it's not a standard header. I qoute from ​http://php.net/manual/en/function.header.php: «frank farmer 04-Aug-2010 02:10 in response to marcel dot glacki at stud dot fh-swf dot de

The "refresh" header in your example is not part of the HTTP standard, it was a proprietary extension invented by Netscape. It's use is discouraged by the W3C.»

Then we can remove the $is_IIS test from wp-redirect and it doesn't need to be defined there.

Rearrange the loading or constant definition sequence, or move the wp_not_installed function declaration, so that WP_SITEURL is defined at the time of declaration of wp_not_installed(). This will ensure that a redirection location never is a relative URL. A "Location" header should always have an "absoluteURI".

I have also investigated this on IIS7 (Windows Server 2008) and there is no problem with relative URLs in a Location header. This is why this problem seems only to affect IIS6.

The first thing is that his means that in case the server is IIS the redirect method should be the "Refresh" header. Othwerwise the redirect method should be the "Location" header. This is strange, because the Location header also works on IIS.

Thats an IIS5 thing, IIRC, It doesn't support the Location header, or does, but due to other bugs, you're required to use the Refresh header. There's another ticket discussing this, and ultimately, I feel IIS5 support should be dropped entirely.

The third thing is that, on my system, when a redirect is done with a relative URL, the redirect is done "internally". This means that the browser will not know that actual resource served to it. But, strangely, the IIS log file shows the actual wp-admin/install.php as being requested. This is very, very strange to me, and I have no explaination. I have no other IIS6 systems to etst this on.

Sounds strange, but that confirms what I was thinking, The redirect wasn't happening to the browser, so the form wasn't getting a correct URL.

WP_SITEURL is never defined by WordPress, This is a constant which can be defined in wp-config.php to override WordPress's database option site_url.

I think there are 2 things that need to be done here, And both are covered by other tickets:

Force all redirects to be absolute (whether that be by removing the relative calls and fixing them, or handling it internally in wp_redirect) - #14062

Remove the Refresh header entirely, and leave it for a Plugin to support if required? - #10187

I think we can close this ticket as a duplicate of those if fixing those will resolve the problems here.