-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Case mismatch in SCRIPT_NAME
on IIS with Rewrite module
#11981
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Per this similar issue a few years ago, and the fact that CGI variables like SCRIPT_NAME and REQUEST_URI basically come directly from the SAPI layer (so IIS), I'm pretty sure this is going to be an IIS oddity. Have you checked if there's something you can do within Symfony to handle this? |
Yes, but it would make the whole base URL detection more fuzzy for everyone: derrabus/symfony-http-foundation@a8828ba This is basically the fix that is suggested by the person who answered the issue you've linked. |
…riteModule (derrabus) This PR was merged into the 5.4 branch. Discussion ---------- [HttpFoundation] Fix base URI detection on IIS with UrlRewriteModule | Q | A | ------------- | --- | Branch? | 5.4 | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | Workaround for php/php-src#11981 | License | MIT | Doc PR | N/A See the linked PHP issue for details on the issue I'm working around. If I setup a Symfony application in a IIS virtual directory and use UrlRewriteModule to rewrite all requests to my front controller script, routing requests might fail if I spell the virtual directory with once with lowercase and afterwards with uppercase letters or vice versa. This PR detects if we're on IIS with active URL rewriting and switches to a more fuzzy base URL detection in that case. Commits ------- 26aec0f [HttpFoundation] Fix base URI detection on IIS with UrlRewriteModule
We've added a workaround to Symfony, see symfony/symfony#51424. That being said, it would of course be better if we didn't need it. |
Description
I'm encountering a strange behavior on IIS regarding the
$_SERVER['SCRIPT_NAME']
variable.On a Windows 11 machine, I have an IIS running with PHP via FastCGI. I've configured a virtual directory named
routingtest
. in that directory, I have an index.php file that just dumps the script name and the request URI.So, if I point my browser to
http://localhost/routingtest/index.php/foo/bar
, I see the expected output:Since directory and file names are case-insensitive in Windows and IIS, I can reach the same script as
http://localhost/RoutingTest/index.php/foo/bar
and the two variables reflect the different case:That's still as it should be. Now, I add a rewrite rule because I want to get rid of the
index.php
in my URLs:Calling
http://localhost/routingtest/foo/bar
:Looks correct. Calling
http://localhost/RoutingTest/foo/bar
:Note how
SCRIPT_NAME
still contains the value from the first request whileREQUEST_URI
is updated correctly. If I restart the IIS and make the two requests in reverse order, I get:http://localhost/RoutingTest/foo/bar
:http://localhost/routingtest/foo/bar
:This means the first request after the IIS has started controls how
SCRIPT_NAME
is reported for all subsequent requests until the server is restarted again. This behavior confuses e.g. Symfony's HttpFoundation which usesSCRIPT_NAME
andREQUEST_URI
to determine the base path to the front controller script.I don't really know if this is a bug in PHP or if this has to be fixed in IIS or the rewrite module. If I have to take this somewhere else, please point me into that direction.
PHP Version
8.1.22
Operating System
Windows 11
The text was updated successfully, but these errors were encountered: