Site inaccessible after upgrade to 3.1, due to endless canonical redirects

[knutsp]

I have two sites running on IIS6 with fastCGI. Both runs in a subfolder, like ​http://sparhell.no/knut/

Both sites failed to display the front page, or any published post or archive after upgrading to 3.1. The browsers (any) complains that the site has a redirect loop. Unpublisged posts displays in preview mode.

All plugins deactivated, the theme as Twenty Ten.

I searched for help and found a plugin by Mark Jaquith that disables canoncal redirect by this:

remove_filter('template_redirect', 'redirect_canonical');

This worked immediately. I have upgraded ten other sites today with no such problem, on IIS7 and Linux, but none of them was residing in a subfolder. So I am not yet able to tell what triggers this behaviour, IIS6, subfolder or both.

[knutsp]

It's definetely a IIS6 issue. Try loading ​http://elpron.no/ a brand new test site, out of the box, installed on IIS6. No problems whatsoever on IIS7.

[nacin]

Bumping to 3.1.1 and critical due to pretty much everyone reporting this: ​http://wordpress.org/support/topic/windows-server-infinite-redirect-after-upgrading-to-31?replies=45.

We still support IIS6.

[ryan]

See also #10187

[ryan]

r16797 seems like it would let IIS 6 slip past the return.

[ryan]

I don't have IIS to test with, but that should prevent IIS 6 from descending into redirect_canonical().

[jamesisin]

If I can provide any assistance I have created a new blog under my domain and can use it (or another) as a testbed.

​http://wordpress.org/support/topic/front-end-in-redirect-loop-back-end-ok

[dd32]

Just testing with IIS6.0, And i'm not running into this at all, Canonical redirects work as expected. However, that's using /?p= or /index.php/postname/ permastructs.

Is there any identified configuration which is failing? ISAPIRewrite? IIS using non-fcgi PHP, certain versions of PHP?

[jamesisin]

I'm running SBS 2003 R2 with IIS 6 (I assume) and PHP5 with MySQL.

[dd32]

Replying to jamesisin:

I'm running SBS 2003 R2 with IIS 6 (I assume) and PHP5 with MySQL.

Same server setup that I'm running here, Do you have any rewrite methods enabled on the server? Can we get a phpinfo() dump / public page?

[jamesisin]

Sounds ok to me. Can you link me to instructions?

[hereswhatidid]

The issue occurs with any permalink structure other than the /?p= or /index.php/. I don't think either of those formats actually do any rewriting, they just parse the values passed via the query string.

[ryan]

dd32, why should IIS6 always be allowed through but not IIS7 if it doesn't support permalinks? Seems all IIS should be allowed through if IIS6 is allowed. In that case the IIS checks at the top of redirect_conical() are pointless. If we want to allow only permalink supporting IIS through, my patch should do that.. r16904 changed $is_IIS to $is_iis7 and I don't really see why.

[Ipstenu]

FYI, this seems to not JUST affect IIS. I caught an apache build with it: ​http://wordpress.org/support/topic/31-rewrites?replies=6

[ryan]

Replying to Ipstenu:

FYI, this seems to not JUST affect IIS. I caught an apache build with it: ​http://wordpress.org/support/topic/31-rewrites?replies=6

I left a reply. That is due to plugins that do not use add_feed(). r16928 fixed canonical redirects for category feeds. This fix breaks plugins that do not use add_feed() to register their feeds. We might remove canonical redirects for unregistered feeds. I'll open a separate ticket if we decide to do that.

[ryan]

#16704 for the feed issue.

[dd32]

Replying to ryan:

If we want to allow only permalink supporting IIS through, my patch should do that.. r16904 changed $is_IIS to $is_iis7 and I don't really see why.

Honestly,
I'm not sure the reason for the change, it looks like it was an accidental change in r16904. that being said, I cant personally remember why iis is excluded from the canonical code, or only included in certain cases.

If you can reproduce it, and reverting the variable change fixes it for all iis, go for it. But to me, It seems like IIS shouldn't be included in that short-circuit at all, for the simple fact, that we should be able to parse/determine the url just as good as apache, the problem that sounds like is happening, is that the guessed url and the redirect url are always different, in which case, I would prefer to debug why it's not working, rather than just killing it.. (but for 3.1.1, just go ahead and disable it again)

[ryan]

After discussion with dd32, nacin, and MarkJaquith, we've decided to turn off canonical redirects for IIS again until we can figure out what is going on. None of us can reproduce the problem right now, so let's just turn it off and figure it out for 3.2.

[knutsp]

Replying to ryan:

we've decided to turn off canonical redirects for IIS

I see no reason to turn it off for IIS7.x, even if this is a temporary solution until 3.2. I may have missed something, I don't understand the links to URL rewriting, but to me IIS6 and IIS7.x are fundamentally different.

[dd32]

There have been reports for IIS 6 & 7, there is a possibility it's simply due to an old asapi filter or fcgi library, or it could be something different related to IIS.

Simple fact is, It's broken on some hosts now that use IIS, until we can verify what is causing the problem to occur, disabling the redirects is the safest method we can take.

Just to be clear, this does not impact on your ability to use "pretty urls" (ie. /2010/09/test-post/) it just means that those accessing the canonical versions of it will not be redirected this is how it was in WordPress 3.0 and below. We'll revisit for 3.2 once we're happy we've tested on many IIS installs/configurations and tracked down the bugs.

The time between 3.1 and 3.2 should be much shorter than the 3.0-3.1 release cycle, so waiting for 3.2 is a tradeoff that many should be able to make.

[knutsp]

Replying to dd32:

There have been reports for IIS 6 & 7

Ok. Could you give me some examples of such for IIS7?

disabling the redirects is the safest method we can take.

Agree.

this does not impact on your ability to use "pretty urls"

I know, fine.

The time between 3.1 and 3.2 should be much shorter than the 3.0-3.1 release cycle

I know, and this is fine.

I'm very happy that this issue is taken very seriously by core developers and committers. In fact, I'm quite impressed. If necessary to discriminate, declare support for IIS6 somewhat limited when it comes to non-essential functions like canonical redirects, but fully support IIS7.x when possible. IIS6 isn't actually "state-of-the-art" webserver technology in 2011.

[ryan]

(In [17492]) Do not perform canonical redirects for IISto avoid redirect loops on some IIS setups. fixes #16639 for trunk

[ryan]

(In [17493]) Do not perform canonical redirects for IISto avoid redirect loops on some IIS setups. fixes #16639 for 3.1

[markjaquith]

In [21207]:

Reënable canonical redirects for IIS. Let's work out any remaining bugs in this cycle. fixes #20484. reverts [17492]. see #16639

[markjaquith]

In [21215]:

Implement the IIS logic test that #16639 should have gotten back in the day, before it was disabled altogether. IIS canonical redirects now only supported for pretty permalink–supporting IIS7 installs. props nacin. fixes #20484. see #16639

[markjaquith]

In [21217]:

Also switch back the @uses annotation for [21215]. props duck_. see #20484. see #16639