Skip to content

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

Open
derrabus opened this issue Aug 15, 2023 · 3 comments
Open

Case mismatch in SCRIPT_NAME on IIS with Rewrite module #11981

derrabus opened this issue Aug 15, 2023 · 3 comments

Comments

@derrabus
Copy link
Contributor

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.

<?php

var_dump($_SERVER['SCRIPT_NAME']);
var_dump($_SERVER['REQUEST_URI']);

So, if I point my browser to http://localhost/routingtest/index.php/foo/bar, I see the expected output:

string(22) "/routingtest/index.php"
string(30) "/routingtest/index.php/foo/bar"

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:

string(22) "/RoutingTest/index.php"
string(30) "/RoutingTest/index.php/foo/bar"

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:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="FrontController">
                    <match url=".*" />
                    <conditions trackAllCaptures="true">
                        <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
                        <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
                    </conditions>
                    <action type="Rewrite" url="index.php/{R:0}" />
                </rule>
            </rules>
        </rewrite>
    </system.webServer>
</configuration>

Calling http://localhost/routingtest/foo/bar:

string(22) "/routingtest/index.php"
string(20) "/routingtest/foo/bar"

Looks correct. Calling http://localhost/RoutingTest/foo/bar:

string(22) "/routingtest/index.php"
string(20) "/RoutingTest/foo/bar"

Note how SCRIPT_NAME still contains the value from the first request while REQUEST_URI is updated correctly. If I restart the IIS and make the two requests in reverse order, I get:

http://localhost/RoutingTest/foo/bar:

string(22) "/RoutingTest/index.php"
string(20) "/RoutingTest/foo/bar"

http://localhost/routingtest/foo/bar:

string(22) "/RoutingTest/index.php"
string(20) "/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 uses SCRIPT_NAME and REQUEST_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

@damianwadley
Copy link
Member

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?

@derrabus
Copy link
Contributor Author

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.

nicolas-grekas added a commit to symfony/symfony that referenced this issue Aug 21, 2023
…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
@derrabus
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants