It is done this way to work around an IIS bug that causes cookies not to work when using Location: type redirection.
Bug info here: http://support.microsoft.com/kb/q176113/
The code that does this is in the wp_redirect function in wp-includes/pluggable.php
Okay that makes sense at least for IIS 3.0 though 5.0. But most of the new servers that will run WordPress via IIS 6.0 and IIS 7.0 will be penalized because of a bug that was in 3.0 – 5.0. I know that this bug has been fixed, because I do redirects all the time with cookies through ASP.NET.
So edit the code I pointed you to to not do it any more. See if it makes any difference. If so, then consider figuring out a patch to let it detect the version number of IIS so that it can not do that, and then submit the patch to the bugtracker at http://trac.wordpress.org .
But frankly, so much of WordPress (permalinks, rewrites, etc) does not work on IIS to begin with that I doubt it’s a huge concern. This isn’t WordPress’ fault, IIS simply does not support that kind of functionality.
Anyway, nobody seriously runs IIS as a live web platform. I’ve really only ever seen it used internally at Windows based businesses, for a quick and dirty webserver. Anybody looking to make a real website that does real things uses Apache (probably on Linux, but also on Windows). The only real reason to run IIS is if you’re forced to code in ASP or one of the various .NET’s or some other one of Microsoft’s many atrocities committed upon mankind.
You can tell that we don’t support IIS much around here, can’t you? 😉
I will give what you said a try. If you add the following to the bottom of vars.php:
$is_IIS5OrLess = (strpos($_SERVER['SERVER_SOFTWARE'], 'Microsoft-IIS/4') !== false && strpos($_SERVER['SERVER_SOFTWARE'], 'Microsoft-IIS/5') !== false) ? true : false;
This will test if it is an unsupported version of IIS. However this can get ugly putting this everywhere. That is why I think maybe as a future goal the WordPress team can make the detection more task based instead of server based.
For instance variables like:
$is_redirectSupported = $is_IIS && $is_IIS5OrLess == false;
Because the servers are becoming more and more similar with the release of IIS 7.0 integrated FastCGI, etc. Plus with IIS 7.0 integrated pipeline more plug-in options are going to be present for WordPress such as integrated Active Directory support. Including many of the features that are currently loved by Apache such as permalinks, url rewrites, and the others you mentioned.
I think the code base would be greatly enhanced by task based support because servers are going to change. There are even problems with WordPress on Apache 1.3 that are not in 2.0. So to treat all the servers the same just clutters up code with meaningless special cases.
But I don’t want to get in to a server war. Because when it gets down to it we are trying to make the best blog software possible irregardless of server.
I am hoping to prove you wrong about IIS, because I am going to put my WordPress live in a couple hours running on IIS 6.0 with full URL Rewriting support done via a .NET HttpModule. After it is live I would love to have you guys smash against it and give it a work out.
Yeah… Not being a person who works in a Windows shop, I don’t really understand the point of nor use Active Directory. So I don’t really get how it would help WordPress any. Maybe it would be useful, but I think that it’s probably a use that would be relegated to WordPress plugin status, instead of something in the core.
I understand where you’re coming from with the task based idea, but honestly it would be nice if Microsoft would get with the program and simply adhere to the standards so that server-specific hacks like this were not necessary in the first place. The standards are well defined, the fact that Microsoft usually doesn’t follow them doesn’t really help things. I understand the existence of bugs, but a bug that survives until the 6th major version is not a bug, it’s a design flaw.
I do understand that .htaccess is an Apache server specific thing, however there is no way for IIS to do rewrites without additional plugins which a) don’t come with it and b) appear to all be commercial plugins that cost $$$. That kinda sucks compared to a free solution. Even the lighttpd server has rewrite capabilities, they’re just not specific enough to allow the same sort of rewrite that .htaccess allows for, although there may be a trick to doing it that I am unaware of. URL Rewriting is pretty far from new, the fact that it’s not built into IIS is downright disgraceful.
Basically, what I’m saying is that these sort of hacks in the WP code would mostly not be necessary if not for IIS. Admittedly, FastCGI has broken things in the past as well. I’m not aware of any particular incompatibilities that arose in WordPress between Apache 1.3 and 2.0, however. I’ve ran it on both and it seems to work fine either way.
Actually the big URL Rewriters that are used on IIS don’t cost any money. It is only when you add Proxy support in that the ISAPI_Rewrite hits you up for some money.
ISAPI_Rewriter
Ionics ISAPI Rewriter
.NET URL Rewriter and Reverse Proxy
But I understand your position on standardization and version of IIS previous to IIS 7. But I truly believe with IIS 7.0 coming out and native support for FastCGI that a more task based approach from Word Press will yield more solid code. This way each server can be configured individually from the rest, so that you can have an IIS < 6 config and an IIS >= 6 config and an Apache 2.0 config and a Apache 3.0 config.
By the way I promised to post the address to my blog. It is running through a totally free URL Rewriter that I developed in C# that is configured using the Apache mod_rewrite configuration style. (Mine is the last one in the list above)
Coder Journal
I am not trying to sway you to move to IIS 7.0, but I think it is wise as a developer to be informed about changes happening in IIS since WordPress is growing fast on that platform. Not to accuse you of anything, but you guys at WordPress didn’t know that IIS 6.0 fixed that bug, and it has been out for 5+ years now.
But I think you will this post interesting in how, one of the IIS 7.0 team developers, adapted WordPress. To add a plug-in for Active Directory (LDAP) authentication.
http://mvolo.com/blogs/serverside/archive/2007/08/12/IIS-Authentication-plugin-for-the-Wordpress-PHP-blogging-engine.aspx
Enjoy and it was good talking to you, if you ever need a PHP developer working on WordPress that has an understanding of IIS please think of me,
Nick Berardi
Okay, I’m sure it’s just me, but I’m not particularly interested in Windows boxes in the server space, because from my perspective, nobody uses them. I’ve never even seen one, and I’ve been doing this sort of thing professionally at many large companies for ~10 years now.
So as for me, I’m not going to do any development based around IIS, partly because I don’t have access to such a system, but mostly because it seems very, very niche. Who’s the target audience? I think that there are more important problems to be solved first.
However, WordPress is an open contribution system. If you have some kind of idea along these lines, then by all means code it up, create a patch, and stick the patch on the bugtracker at http://trac.wordpress.org . The development is open to the public. Feel free to hop on in. 🙂
You are right I just need to jump in. Hopefully I can make a difference.
Calling IIS a “very, very niche” product is in my opinion very, very naive for the fact that it almost has equal share of the internet with Apache.
Netcraft December 2007 Web Server Survey
And the trend line seems to indicate a decline in Apache and a ramp up in IIS.
