WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

Last modified 22 months ago

#16639 closed defect (bug) (fixed)

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

Reported by: knutsp Owned by:
Milestone: 3.1.1 Priority: normal
Severity: critical Version: 3.1
Component: Canonical Keywords:
Focuses: Cc:

Description

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.

Attachments (1)

16639.diff (818 bytes) - added by ryan 3 years ago.

Download all attachments as: .zip

Change History (26)

comment:1 knutsp3 years ago

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.

comment:2 nacin3 years ago

  • Milestone changed from Awaiting Review to 3.1.1
  • Severity changed from major to critical

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.

comment:3 ryan3 years ago

See also #10187

comment:4 ryan3 years ago

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

ryan3 years ago

comment:5 ryan3 years ago

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

comment:6 jamesisin3 years ago

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

comment:7 dd323 years ago

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?

comment:8 follow-up: jamesisin3 years ago

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

comment:9 in reply to: ↑ 8 dd323 years ago

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?

comment:10 jamesisin3 years ago

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

comment:11 hereswhatidid3 years ago

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.

comment:12 follow-up: ryan3 years ago

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.

comment:13 follow-up: Ipstenu3 years ago

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

comment:14 in reply to: ↑ 13 ryan3 years ago

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.

comment:15 ryan3 years ago

#16704 for the feed issue.

comment:16 in reply to: ↑ 12 dd323 years ago

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)

comment:17 follow-up: ryan3 years ago

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.

comment:18 in reply to: ↑ 17 knutsp3 years ago

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.

comment:19 follow-up: dd323 years ago

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.

comment:20 in reply to: ↑ 19 knutsp3 years ago

Replying to dd32:

There have been reports for IIS 6 & 7

Ok. Could you give me some examples of such?

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.

Version 0, edited 3 years ago by knutsp (next)

comment:21 ryan3 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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

comment:22 ryan3 years ago

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

comment:23 markjaquith22 months ago

In [21207]:

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

comment:24 markjaquith22 months ago

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

comment:25 markjaquith22 months ago

In [21217]:

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

Note: See TracTickets for help on using tickets.