php / php/php-src

Case mismatch in `SCRIPT_NAME` on IIS with Rewrite module

Ouverte
#11,981 3 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Bug OS: Windows SAPI: cgi Status: Needs Triage
Langage dominant
C
Étoiles
40.4k
Forks
8.1k
Merge moyen
2 j 13 h
PR mergées (30 j)
96

Description

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

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Piste de recherche

Commencez par reproduire la séquence avec index.php et la configuration de IIS Rewrite sous Windows 11 avec PHP 8.1.22 via FastCGI. Comparez SCRIPT_NAME et REQUEST_URI entre des requêtes dont la casse diffère, puis déterminez si le comportement provient de PHP ou de IIS/Rewrite. Le travail est terminé lorsque le composant responsable est identifié et qu’une résolution appropriée est documentée ou implémentée.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
php
Domaine
backend
Type d'issue
Bug
Difficulté
4/5
Temps estimé
3-5 jours
Activité
À l'abandon
Clarté
À clarifier
Accessibilité débutants
25/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.