Home > Tipps & Tricks > Zend Framework (1.x) > Zend MVC: Problem mit Helicon Ape

Zend MVC: Problem mit Helicon Ape

Geschrieben von   admin on    Januar 29, 2011

Wer Zend Framework MVC-Anwendungen auf IIS mit Helicons ISAPI_rewrite betreibt, hat normalerweise kein Problem, denn eine kleine Besonderheit, ISAPI_rewrite betreffend, wird von Zend Framework abgefangen: Es wird $_SERVER['HTTP_X_REWRITE_URL'] gesetzt, anstatt $_SERVER['REQUEST_URI'].

Bei einem laufenden Projekt habe ich nun zum zweiten Mal Helicons neuen Ape (APache Emulator) eingesetzt, der ja weitgehende Kompatibilität zu Apache, und zwar nicht nur in Sachen mod_rewrite-Emulation, herstellen soll. Und dabei bin ich auf ein Problem gestossen: Helicon Ape setzt nun zwar REQUEST_URI und (wegen Abwärtskompatibilität) auch HTTP_X_REWRITE_URL, aber es gibt einen Unterschied:

Die .htaccess-Datei für die Website hat folgenden Inhalt:

RewriteEngine On
RepeatLimit 200
RewriteBase

#  Defend your computer from some worm attacks
RewriteRule ^.*(?:global.asa|default\.ida|root\.exe|\.\.).*$ . [NC,F,O]

#Fix missing trailing slash char on folders
RewriteRule ^([^.?]+[^.?/])$ $1/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d [OR]
RewriteCond %{REQUEST_URI} \.(js|ico|gif|jpg|jpeg|png|css)$
RewriteRule ^.*$ - [NC,L]

RewriteRule ^.*$ /index.php [NC,L]

ISAPI_rewrite setzt HTTP_X_REWRITE_URL, ganz korrekt, auf /. Aber leider eben nicht REQUEST_URI, was aber ein altbekanntes Verhalten ist. Ape wiederum setzt hier /index.php/ ein. Und zwar sowohl in REQUEST_URI als auch in HTTP_X_REWRITE_URL. Mir ist noch nicht ganz klar, ob ich vielleicht etwas übersehen habe. Jedenfalls unterscheidet sich das Verhalten. Da mit ISAPI_rewrite  in Zend MVC-Anwendungen URLs der Form http://www.mein.test/suche/, mit Ape aber http://www.mein.test/index.php/suche/ die Folge sind, habe ich mich bis zur Klärung der Sache für den folgenden Patch entschieden:

Zu Beginn der index.php von Zend Framework-MVC-Anwendungen wird bei mir dieser Codeabschnitt eingesetzt:

if (isset($_SERVER['HTTP_X_REWRITE_URL'])) {
    $requestUri = $_SERVER['HTTP_X_REWRITE_URL'];
} else {
    $requestUri = $_SERVER['REQUEST_URI'];
}

$requestUri = preg_replace('%^/index\.php%i', '', $requestUri);
if (isset($_SERVER['HTTP_X_REWRITE_URL'])) {
    $_SERVER['HTTP_X_REWRITE_URL'] = $requestUri;
}
$_SERVER['REQUEST_URI'] = $requestUri;
unset($requestUri);

Somit liegt für den Rest der Anwendung nun, was $_SERVER['REQUEST_URI'] angeht, in jedem Fall die gleiche Situation vor, wie sie auch bei Apaches mod_rewrite vorliegt.

Ich will nicht ausschließen, dass ich, z.B. bei der Konfiguration von Helicon Ape, irgend etwas übersehen habe, konnte das Problem aber bisher nicht klären. Vielleicht hilft diese Lösung ja auch anderen Betroffenen.

Tja. Dabei hatte ich doch gehofft, dass mit Helicon Ape nun endlich die Zeiten vorbei sind, wo man für IIS noch nachfeilen muss, was Rechtevergabe und URL-Rewriting angeht. Schließlich gehen ja fast alle Quellen zur Konfiguration von PHP-Webanwendungen immer noch von einem Apache-Webserver aus.

Nachtrag!

Mittlerweile, nach Kommunikation mit dem Support von Helicon, konnte das Problem etwas enger eingekreist werden:
Ape liefert in REQUEST_URI, ganz korrekt, "/". Jedoch in HTTP_X_REWRITE_URL "/index.php". HTTP_X_REWRITE_URL wird nur als Massnahme zur Abwärtskompatibilität mit ISAPI_rewrite gesetzt. Aber leider eben falsch. Das Problem entsteht nun dadurch, dass das Routing in Zend Framework zuerst auf HTTP_X_REWRITE_URL prüft, um eben auch ISAPI_rewrite bedienen zu können. Der Bugfix lässt allerdings nach wie vor auf sich warten. In der Zwischenzeit verwende ich nun den folgenden, etwas simpleren, Codeabschnitt, auch wenn er etwas merkwürdig aussehen mag:

if (isset($_SERVER['REQUEST_URI'])) {
    // Apache mit mod_rewrite oder z.B. Helicon Ape
    $requestUri = $_SERVER['REQUEST_URI'];
} else if (isset($_SERVER['HTTP_X_REWRITE_URL'])) {
    // Helicon ISAPI_rewrite
    $requestUri = $_SERVER['HTTP_X_REWRITE_URL'];
}
if (isset($_SERVER['HTTP_X_REWRITE_URL'])) {
    unset($_SERVER['HTTP_X_RERITE_URL']);
}

$_SERVER['REQUEST_URI'] = $requestUri;

Damit kein falscher Eindruck aufkommt: An sich ist Helicons Ape eine absolut geniale Sache: Die Kompatibilität mit Apache ist (ansonsten) wirklich verblüffend. Wer, aus welchen Gründen auch immer, abseits ASP.NET Webanwendungen auf dem IIS ab 7.x betreibt, kann nun endlich irgendwelche besonderen Maßnahmen, z.B. Umschreiben des URL-Rewriting für das IIS-Modul, oder irgendwelche Klimmzüge bei der Rechtevergabe, um den .htaccess-Mechanismus nachzubauen, vergessen. Helicon Ape installieren, die Domain freischalten, und gut ist! Bis auf diesen einen, obern geschilderten Umstand, habe ich mit Ape bisher nur gute Erfahrungen gemacht!

Kommentare

Kommentar schreiben



(Ihre E-Mail-Adresse wird nicht angezeigt.)


Ungültiger Sicherheitscode

Bitte klicken Sie das Bild an, um einen neuen Sicherheitscode zu laden.