Helicon Tech: ISAPI_Rewrite 2 and 3 side-by-side

ISAPI_Rewrite 2.x
Helicon Tech : ISAPI_Rewrite 2.x

Topic: ISAPI_Rewrite 2 and 3 side-by-side

Author

Message

<< Prev Topic | Next Topic >>

Digiover
Newbie
Newbie

Joined: 14 October 2005
Location: Netherlands
Online Status: Offline
Posts: 18

Posted: 11 March 2010 at 9:54am \| IP Logged

Since last night we're running versions 2 and 3 of ISAPI_Rewrite side-by-side. Configured globally in IIS.

(we want to phase out version 2 slowly)

In our test set-up, this never caused problems (with existing blogs, CMS-s and scripts). Now, customers report strange problems, all related to REQUEST_URI and HTTP_X_REWRITE_URL server variables.

Even though they print exactly the same information to the screen:

Code:

<?php

 echo $_SERVER['REQUEST_URI'] ."<br/>";

 echo $_SERVER['HTTP_X_REWRITE_URL'];

?>

scripts that rely on HTTP_X_REWRITE_URL stopped working properly. Changing the code to let it use REQUEST_URI fixes the problem.

This goes for PHP-scripting, but for ASP (VBScript) too.

Any ideas?

__________________
Met vriendelijke groet / Best regards,
Jan Reilink, VEVIDA Nederland BV

Postbus 329, 9700 AH GRONINGEN, +31(0)50 - 5492234

Anton
Admin Group

Joined: 30 January 2007
Location: Ukraine
Online Status: Offline
Posts: 10489

Posted: 12 March 2010 at 2:14am \| IP Logged

"we're running versions 2 and 3 of ISAPI_Rewrite side-by-side. Configured globally in IIS."
- I suggest to have ISAPI_Rewrite dll (either v2 or v3 but not both) registered on per-site level for each site. That seems to be more logical
and should eliminate the problem you currently have.

__________________
Regards,
Anton

Digiover
Newbie
Newbie

Joined: 14 October 2005
Location: Netherlands
Online Status: Offline
Posts: 18

Posted: 12 March 2010 at 8:14am \| IP Logged

I could trace it back to HTTP_X_REWRITE_URL not having the original URI, as REQUEST_URI has. But it contains the rewritten URL. When version 2 and 3 run side-by-side on a server.

For example:

Code:

if (isset($_SERVER['HTTP_X_REWRITE_URL']))

{

$_SERVER['REQUEST_URI'] = $_SERVER['HTTP_X_REWRITE_URL'];

}

$uri = $_SERVER['REQUEST_URI'];

print $uri;

A RewriteRule like:

Code:

RewriteRule /test/(.*) /test/index.php

prints /index.php. Not /test/rewrittenfilename.php?id=12&bla=-234klsdf.

Removing the "If"-statement (and thus keeping the original REQUEST_URI) solves this. For IIS/FastCGI webservers, which have the REQUEST_URI server variable.

For short: customers who are affected by this, are now merged to ISAPI_Rewrite v3 (rewrite httpd.ini rules to .htaccess and remove httpd.ini file)

__________________
Met vriendelijke groet / Best regards,
Jan Reilink, VEVIDA Nederland BV

Postbus 329, 9700 AH GRONINGEN, +31(0)50 - 5492234

Anton
Admin Group

Joined: 30 January 2007
Location: Ukraine
Online Status: Offline
Posts: 10489

Posted: 15 March 2010 at 2:36am \| IP Logged

Could you please clarify whether it's all fine now or you still encounter issues?
If you do, in what cases?

__________________
Regards,
Anton

Digiover
Newbie
Newbie

Joined: 14 October 2005
Location: Netherlands
Online Status: Offline
Posts: 18

Posted: 15 March 2010 at 3:41pm \| IP Logged

For me it's all fine, for (some) customers it is not.

A little background information:

By standard design IIS does not provide the REQUEST_URI server variable. If ISAPI_Rewrite 2 is installed, you can use the HTTP_X_REWRITE_URL server variable. It contains the same information (full URI).

When you install FastCGI for IIS (http://iis.net/fastcgi), IIS does provide the REQUEST_URI server variable. Both server variables now contain the same information, which is not a problem.

However, many (many, many, ...) customers added a piece of code to their PHP scripts, to provide a REQUEST_URI server variable, when it was not available (like in a non-FastCGI environment). The PHP code is known and is:

Code:

if (isset($_SERVER['HTTP_X_REWRITE_URL'])) {

  $_SERVER['REQUEST_URI'] = $_SERVER['HTTP_X_REWRITE_URL'];

}

this provides REQUEST_URI, so scripts (like forums, blogs, and so on) wouldn't have to be altered, code-wise.

Still no problem if only ISAPI_Rewrite 2 is installed.

When you install ISAPI_Rewrite 2 and 3 side-by-side, and the PHP code exists, then rewrites are broken. Now REQUEST_URI contains the real URI, and HTTP_X_REWRITE_URL only the rewritten URL.

This then breaks the altered REQUEST_URI, when the above PHP code is used to put the data in the REQUEST_URI server variable.

Solution:
1) remove the PHP code on IIS/FastCGI web servers
2) rewrite the ISAPI_Rewrite 2 httpd.ini file to ISAPI_Rewrite 3 .htaccess file.

(or 3: don't run them side-by-side)

This problem never appeared in our test set-up, because when we installed FastCGI, we noticed the availability of the REQUEST_URI server variable and our test-code no longer relies on HTTP_X_REWRITE_URL.

But seriously: More and more web hosting providers switch to FastCGI for IIS 6.0, and it's default on IIS 7.0/7.5. It provides real REQUEST_URI. So why not remove the PHP sample code from http://www.helicontech.com/isapi_rewrite/doc/concept.htm ?

Anton
Admin Group

Joined: 30 January 2007
Location: Ukraine
Online Status: Offline
Posts: 10489

Posted: 16 March 2010 at 6:16am \| IP Logged

Thanks a lot for sharing experience.
We'll fix the docs.

__________________
Regards,
Anton

If you wish to post a reply to this topic you must first login
If you are not already registered you must first register

Printable version

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot delete your posts in this forum
You cannot edit your posts in this forum
You cannot create polls in this forum
You cannot vote in polls in this forum