Umgeschriebene URLs mit einer Parameterlänge> 255 funktionieren nicht


12

Ich benutze mod_rewrite, um URLs wie diese umzuschreiben:

http://example.com/1,2,3,4/foo/

Auf diese Weise in .htaccess:

RewriteEngine On
RewriteRule ^([\d,]+)/foo/$ /foo.php?id=$1 [L,QSA]

Es funktioniert einwandfrei, außer wenn "1,2,3,4" in eine Zeichenfolge mit mehr als 255 Zeichen umgewandelt wird, gibt Apache "403 Forbidden" zurück.

foo.php?id=1,2,3,4Selbst mit einer sehr langen ID-Zeichenfolge ist ein direkter Besuch kein Problem. Dies ist jedoch keine Option für mich.

Gibt es Apache oder eine andere Einstellung, die ich anpassen sollte?

UPDATE : Ich habe RewriteLog mit RewriteLogLevel 9 aktiviert. Mit einer kurzen ID-Zeichenfolge werden mehrere Zeilen in meiner Protokolldatei angezeigt. Wenn die ID-Zeichenfolge jedoch größer als 255 Zeichen ist, wird nichts protokolliert (scheint, als würde mod_rewrite nicht einmal ausgeführt?).

Wenn Sie diese Frage interessant / hilfreich finden, stimmen Sie sie bitte hoch.


Könnte dies ein reguläres Problem sein? Haben Sie überprüft, ob die umgeschriebene Anforderung für Zeichenfolgen mit mehr als 255 Zeichen korrekt ist? Wenn nicht, könnten Sie vielleicht die Pre- und Post-Rewrite-Anfragen posten.
Tomjedrz

3
Aktivieren Sie die Protokollierung von mod_rewrite mit RewriteLogund RewriteLogLevelSie können sehen, was abgeglichen wird und wie es tatsächlich umgeschrieben wird. Ich würde vermuten, dass nur 255 Zeichen kopiert werden $1und dass idder Client nicht berechtigt ist, diese zu sehen. Apache gibt die 403 zurück. Ich habe mir den Code nicht angesehen, aber es könnte sein, dass Apache manipuliert die Rückreferenz in einem festen 256-Byte-Puffer (der 256. ist für den terminierenden NULL-Wert reserviert).
James Sneeringer

Siehe Update in Frage - nichts ist für lange Parameter protokolliert
philfreo

Antworten:


8

Glauben Sie, Sie stoßen auf eine Einschränkung des Dateisystems?

Möglicherweise beträgt der maximale Dateiname 255 Byte. Wenn Apache oder die mod_rewrite-Regel überprüfen, ob die Datei vorhanden ist, gibt das Betriebssystem einen Fehler an Apache zurück.

Wenn Sie eine Regel in Ihre .htaccess-Datei einfügen, ist es zu spät, um das Problem zu umgehen. Apache hat bereits versucht, den Dateinamen und den ausgelösten Dateisystemfehler '(36) Dateiname zu lang' zu ermitteln und einen 403-Fehler zurückgegeben.

Möglicherweise können Sie das URL-Muster in Ihrer App ändern. bis zu 255 Zeichen von Schrägstrich zu Schrägstrich.

BEARBEITEN: Hier finden Sie eine ausführliche Antwort auf dieses Problem. Ich habe meine von dort ausgeliehen.


Ja, das ist derzeit alles, was wir tun können. Ich hoffe jedoch auf einen Workaround oder eine Optimierung.
Philfreo

3
Microspino, Sieht aus, als hätten Sie einen Teil Ihrer Antwort aus @ Jeff Clarks Antwort hier ausgeschnitten und eingefügt: serverfault.com/questions/120397/… . Sie sollten einen Hyperlink zu dieser Antwort erstellen, damit er eine gewisse Bekanntheit erlangt.
Stefan Lasiewski

@ Stefan Lasieswski: Du hast recht, ich habe eine Referenz hinzugefügt.
Microspino

Sie denken also, dass Apache versucht, die angeforderte Datei unabhängig davon zu statisieren - ich meine, das könnte der einzige Weg sein, um zu erklären, dass die zu lange URL nicht einmal von der Rewrite-Engine
erfasst wird

Ja, das ist meine Idee, obwohl ich denke, dass es aus einer Reihe von Gründen vermieden werden sollte, so lange URLs und Dateinamen zu haben. Der beste Rat, den ich mir vorstellen kann, ist, etwas am URL-Muster zu ändern, wenn der Dateiname noch nicht zu lang ist.
Microspino

2

Es gibt eine ähnliche Frage zu diesem Limit hier :

Möglicherweise stoßen Sie auf eine Einschränkung des zugrunde liegenden Dateisystems

Ich weiß nicht, ob Sie REQUEST_FILENAME irgendwo in Ihrer .htaccess-Konfiguration verwenden. Sie wissen also nicht, ob die bereitgestellte Lösung funktionieren wird.


Das macht Sinn, aber nein, das bin ich nicht. Ich habe meine Frage so bearbeitet, dass sie die gesamte .htaccess-Datei enthält. Andere Ideen?
Philfreo

Gemäß "Technische Details zu Apache mod_rewrite" unter httpd.apache.org/docs/trunk/rewrite/tech.html "Obwohl mod_rewrite URLs in URLs, URLs in Dateinamen und sogar Dateinamen in Dateinamen umschreibt, bietet die API derzeit nur eine URL-to -Dateiname Haken. ". Auch wenn Sie keine tatsächliche Datei gefunden haben, hat der URL zum Dateinamen-Hook möglicherweise das Ressourcenlimit des Betriebssystems erreicht.
Stefan Lasiewski

0

Auf jeden Fall eine interessante Frage. Führen Sie mod_security aus und versuchen Sie es, wenn ja, ohne es? Vielleicht mag es einfach keine langen Pfadnamen oder langen Pfadnamen mit nicht kodierten Kommas? ^^

Obwohl es sich instinktiv eher wie eine Beschränkung des URL-Pfads oder zumindest einzelner Segmente davon oder der zugrunde liegenden Dateisysteminterpretation davon anfühlt, wie GmonC es geschrieben hat. Das würde auch erklären, warum die reguläre URL mit dem langen Teil in der Abfragezeichenfolge gut funktioniert.

Ich denke, dass ältere ASP.NET verwendet, um eine Anforderungspfadbegrenzung von ~ 260 Zeichen oder etwas zu haben.


Siehe Update zur Frage. Und nein, ich sehe keine mod_security-Datei in /usr/include/apache2/oder /usr/lib/apache2/modules/(aber ich sehe dort mod_rewrite), also gehe ich davon aus, dass sie nicht installiert ist.
Philfreo

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.