Re-enable redirect_canonical for IIS

[amattie]

Canonical redirects within IIS 7 were disabled in #16639. The comment then was "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." Now that it's been > 1yr and 3.4 is right around the corner, would it be possible for this issue to be revisited?

I develop in Windows / IIS7 and deploy to Linux and so the functionality mismatch caused me a bit of grief until I figured out what was going on. As others have pointed out, it seems silly to discriminate against a perfectly good web server that would otherwise handle redirects just fine.

[knutsp]

+1

[nacin]

Sorry this got lost.

[SergeyBiryukov]

Related: #21011

[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

[nacin]

[21207] (which came from whatever [17492] reverted, I know) has some logic issues. If you're on IIS6, you end up with canonical redirects. This is quite possibly what the original bug was in #16639...

What this should be is || ( $is_IIS && ! iis7_supports_permalinks() ). Thus, if you're on IIS (any version), you don't get canonical redirects, unless you have IIS7 and it supports permalinks.

[nacin]

Yeah, [21207] would re-introduce the bug in #16639. See 16639.diff:ticket: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