Gli URL riscritti con lunghezza del parametro> 255 non funzionano

12

Sto usando mod_rewrite per riscrivere gli URL in questo modo:

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

In questo modo in .htaccess:

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

Funziona bene, tranne quando "1,2,3,4" si trasforma in una stringa più lunga di 255 caratteri, Apache restituisce un "403 proibito".

Non c'è nessun problema a visitare foo.php?id=1,2,3,4direttamente, anche con una stringa id molto lunga, tuttavia questa non è un'opzione per me.

C'è qualche Apache o altre impostazioni che dovrei modificare?

AGGIORNAMENTO : Ho attivato RewriteLog con RewriteLogLevel 9. Con una stringa ID breve, ottengo diverse righe nel mio file di registro. Ma quando la stringa id è maggiore di 255 caratteri, non viene registrato nulla (sembra che mod_rewrite non stia nemmeno eseguendo?).

Se trovi questa domanda interessante / utile, per favore votala.

— philfreo
fonte

Potrebbe essere un problema regex? Hai verificato che la richiesta riscritta sia corretta per stringhe più lunghe di 255 caratteri? In caso contrario, forse potresti inviare le richieste pre e post riscrittura.

— tomjedrz,

3

Abilita la registrazione di mod_rewrite con RewriteLoge RewriteLogLevelcosì puoi vedere cosa viene abbinato e come viene realmente riscritto. Immagino che vengano copiati solo 255 caratteri $1, e questo finisce per essere un idaspetto che il client non è autorizzato a vedere, quindi Apache restituisce il 403. Non ho guardato il codice, ma potrebbe essere che Apache manipoli il backreference in un buffer a 256 byte fisso (il 256 ° è riservato al NULL di terminazione).

— James Sneeringer,

Vedi aggiornamento in questione - non viene registrato nulla per i parametri lunghi

— philfreo,

8

Pensi di avere un limite al file system?

Può essere che la lunghezza massima del nome file sia di 255 byte e quando apache o la regola mod_rewrite verifica se il file esiste un errore viene restituito ad apache dal sistema operativo.

Se metti qualche regola nel tuo file .htaccess, è troppo tardi per aggirare il problema. Apache avrà già provato a stat il nome del file e ha generato l'errore del file system '(36) Nome file troppo lungo', restituendo un errore 403.

Forse potresti cambiare il pattern URL all'interno della tua app. fino a un massimo di 255 caratteri da barra a barra.

EDIT: cerca qui una risposta dettagliata a questo problema. Ho preso in prestito il mio da lì.

— microspino
fonte

Sì, questo è attualmente tutto ciò che possiamo fare, spero comunque per una soluzione alternativa o per modificare.

— philfreo,

3

Microspino, sembra che tu abbia tagliato e incollato parte della tua risposta dalla risposta di @Jeff Clark qui: serverfault.com/questions/120397/… . Dovresti creare un collegamento ipertestuale a quella risposta, in modo che ottenga una certa notorietà.

— Stefan Lasiewski,

@Stefan lasieswski: hai ragione, ho aggiunto un riferimento.

— microspino,

quindi stai pensando che forse Apache sta provando a stat il file richiesto indipendentemente - voglio dire, potrebbe essere l'unico modo per spiegare che l'URL troppo lungo non viene nemmeno raccolto dal motore di riscrittura ...

— HorusKol

Sì, questa è la mia idea, anche se penso che in generale avere URL e nomi di file così lunghi debbano essere evitati per una serie di motivi. Quindi il miglior consiglio che potrei pensare forse è quello di cambiare qualcosa nel pattern URL se il nome del file non è già troppo lungo.

— microspino,

2

C'è una domanda simile su questo limite qui :

È possibile che si stia verificando una limitazione del file system sottostante

Non so se stai usando REQUEST_FILENAME da qualche parte nella tua configurazione .htaccess, quindi non so se la soluzione fornita funzionerà.

— GmonC
fonte

Questo ha senso, ma no, non lo sono. Ho modificato la mia domanda per includere il file .htaccess nella sua interezza. Altre idee?

— philfreo,

Secondo "Apache mod_rewrite Dettagli tecnici" su httpd.apache.org/docs/trunk/rewrite/tech.html "Sebbene mod_rewrite riscriva gli URL in URL, gli URL in nomi di file e persino i nomi di file in nomi di file, l'API attualmente fornisce solo un URL a -filename hook. ". Quindi, anche se non stai colpendo un vero file, forse l'URL del hook del nome del file sta colpendo il limite delle risorse del sistema operativo?

— Stefan Lasiewski,

0

Sicuramente una domanda interessante. Esegui mod_security e, in tal caso, provato senza di essa? Forse semplicemente non gli piacciono i nomi di percorsi lunghi o nomi di percorsi lunghi con virgole non codificate? ^^

Sebbene istintivamente sembri più un limite al percorso dell'URL o almeno singoli segmenti di esso o l'interpretazione del filesystem sottostante come ha scritto GmonC. Ciò spiegherebbe anche perché l'URL normale con la parte lunga nella stringa di query funziona correttamente.

Penso che ASP.NET precedente avesse un limite di percorso di richiesta di ~ 260 caratteri o qualcosa del genere.

— Oskar Duveborn
fonte

Vedi aggiornamento alla domanda. E no, non vedo un file mod_security in /usr/include/apache2/o /usr/lib/apache2/modules/(ma vedo mod_rewrite lì) quindi presumo che non sia installato.

— philfreo,

0

Sei disposto a cambiare i server http? Quindi considera nginx invece di apache.

E usa http://wiki.nginx.org/NginxHttpRewriteModule

— JavaRocky
fonte

Veramente? Non c'è modo di farlo in Apache?

— philfreo,