Les URL réécrites avec une longueur de paramètre> 255 ne fonctionnent pas

12

J'utilise mod_rewrite pour réécrire des URL comme celle-ci:

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

En faisant cela dans .htaccess:

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

Cela fonctionne très bien, sauf lorsque "1,2,3,4" se transforme en une chaîne de plus de 255 caractères, Apache renvoie un "403 interdit".

Il n'y a aucun problème à visiter foo.php?id=1,2,3,4directement, même avec une chaîne d'identification très longue, mais ce n'est pas une option pour moi.

Existe-t-il un Apache ou un autre paramètre à modifier?

MISE À JOUR : J'ai activé RewriteLog avec RewriteLogLevel 9. Avec une courte chaîne d'identification, j'obtiens plusieurs lignes dans mon fichier journal. Mais lorsque la chaîne id est supérieure à 255 caractères., Rien n'est enregistré (il semble que mod_rewrite ne s'exécute même pas?).

Si vous trouvez cette question intéressante / utile, veuillez la voter.

apache-2.2  mod-rewrite  url  querystring 
— philfreo
source
Serait-ce un problème d'expression régulière? Avez-vous vérifié que la demande réécrite est correcte pour les chaînes de plus de 255 caractères? Sinon, vous pouvez peut-être publier les demandes de pré et post-réécriture.
— tomjedrz
3
Activez la journalisation de mod_rewrite avec RewriteLoget RewriteLogLevelainsi vous pouvez voir ce qui est mis en correspondance et comment il est vraiment en cours de réécriture. Je suppose que seuls 255 caractères sont copiés dans $1, et cela finit par être un idque le client n'est pas autorisé à voir, donc Apache renvoie le 403. Je n'ai pas regardé le code, mais il se pourrait qu'Apache manipule la référence arrière dans un tampon fixe de 256 octets (le 256e est réservé pour la terminaison NULL).
— James Sneeringer
Voir la mise à jour en question - rien n'est enregistré pour les paramètres longs
— philfreo

Réponses:

8

Pensez-vous que vous rencontrez une limitation du système de fichiers?

La longueur maximale du nom de fichier peut être de 255 octets et lorsque apache ou la règle mod_rewrite vérifie si le fichier existe, une erreur est renvoyée à apache par le système d'exploitation.

Si vous placez une règle dans votre fichier .htaccess, il est trop tard pour contourner le problème. Apache aura déjà essayé de déclarer le nom de fichier et l'erreur de système de fichiers levée '(36) Nom de fichier trop long', renvoyant une erreur 403.

Vous pouvez peut-être modifier le modèle d'URL dans votre application. jusqu'à un maximum de 255 caractères de barre oblique à barre oblique.

EDIT: regardez ici pour une réponse détaillée à ce problème. J'ai emprunté le mien à partir de là.

— microspino
source
Oui, c'est actuellement tout ce que nous pouvons faire, j'espère cependant une solution de contournement ou un réglage.
— philfreo
3
Microspino, On dirait que vous avez coupé et collé une partie de votre réponse de la réponse de @Jeff Clark ici: serverfault.com/questions/120397/… . Vous devez créer un lien hypertexte vers cette réponse, afin qu'il obtienne une certaine notoriété.
— Stefan Lasiewski
@Stefan lasieswski: vous avez raison, j'ai ajouté une référence.
— microspino
donc, vous pensez peut-être qu'Apache essaie de statuer le fichier demandé indépendamment - je veux dire, cela pourrait être le seul moyen d'expliquer que l'URL trop longue n'est même pas récupérée par le moteur de réécriture ...
— HorusKol
Oui, c'est mon idée, bien que je pense qu'en général, avoir des URL et des noms de fichiers aussi longs devrait être évité pour un certain nombre de raisons. Donc, le meilleur conseil que je pourrais penser est peut-être de changer quelque chose dans le modèle d'URL si le nom de fichier n'est pas déjà trop long.
— microspino
2

Il y a une question similaire à propos de cette limite ici :

Vous rencontrez peut-être une limitation du système de fichiers sous-jacent

Je ne sais pas si vous utilisez REQUEST_FILENAME quelque part dans votre configuration .htaccess, alors je ne sais pas si la solution fournie va fonctionner.

— GmonC
source
Cela a du sens, mais non, je ne le suis pas. J'ai modifié ma question pour inclure le fichier .htaccess dans son intégralité. D'autres idées?
— philfreo
Selon "Apache mod_rewrite Technical Details" sur httpd.apache.org/docs/trunk/rewrite/tech.html "Bien que mod_rewrite réécrit les URL en URL, les URL en noms de fichiers et même les noms de fichiers en noms de fichiers, l'API ne fournit actuellement qu'une URL vers -nom de fichier hook. ". Donc, même si vous ne frappez pas un fichier réel, l'URL du hook de nom de fichier atteint peut-être la limite de ressources du système d'exploitation?
— Stefan Lasiewski
0

Certainement une question intéressante. Exécutez-vous mod_security et si oui, avez-vous essayé sans? Peut-être qu'il n'aime tout simplement pas les noms de chemin long ou les noms de chemin long avec des virgules non codées? ^^

Bien que cela ressemble instinctivement plus à une limite sur le chemin de l'url ou au moins à des segments individuels de celui-ci ou à l'interprétation du système de fichiers sous-jacente comme l'écrit GmonC. Cela expliquerait également pourquoi l'URL régulière avec la partie longue dans la chaîne de requête fonctionne correctement.

Je pense qu'ASP.NET plus ancien avait une limite de chemin de requête de ~ 260 caractères ou quelque chose aussi.

— Oskar Duveborn
source
Voir la mise à jour de la question. Et non, je ne vois pas de fichier mod_security dans /usr/include/apache2/ou /usr/lib/apache2/modules/(mais j'y vois mod_rewrite), donc je suppose qu'il n'est pas installé.
— philfreo
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.