Zend Framework: URL codificato con decodifica Apache invece di passare l'URL codificato?

Question

Sto testando la mia applicazione Zend Framework usando Selenium e PHPUnit. Ho un test che deve aprire un URL che contiene un URL codificato.

$redirectToLocation = urlencode('/myothercontroller/action'); // %2Fmyothercontroller%2Faction 
$this->openAndWait('/controller/action/thenRedirectTo/' . $redirectToLocation); 

Ma quando ho eseguito la mia prova, il browser provato ad aprire l'URL decodificato:

/controller/action/thenRedirectTo//myothercontroller/action 

Cosa devo fare per ottenere il selenio per aprire l'URL codificato?

Aggiornamento: In realtà ... si rivela il selenio sta facendo il suo lavoro, ma sembra come se Apache sta decodificando l'URL prima che arrivi al controller:

The requested URL /controller/action/thenRedirectTo//myothercontroller/action was not found on this server. 

Come devo risolvere questo problema ?

Aggiornamento: Ecco un'intera conversazione sullo stesso problema che sto riscontrando: http://old.nabble.com/URL-Encoding-td18850769.html. La loro soluzione alternativa era codificare l'URL in base64, ma non è abbastanza buono per me. Posso usare questa soluzione a breve termine, ma voglio sapere qual è la vera causa di questo problema, quindi posso eliminarlo.

Aggiornamento: Ho un collega che pensa che ci possa essere un problema con il modo in cui Zend Framework instrada la richiesta. Pensi che potrebbe essere il caso?

Answer 1

Interessante problema. Personalmente non ho mai avuto problemi a passare un altro URL in una stringa di query, cioè/controller/action/thenRedirectTo? Q =% 2Fmyothercontroller% 2Faction, ma non ho usato Apache da molto tempo, e non è esattamente quello che si ' sto cercando di fare.

Una possibile soluzione potrebbe essere il doppio URL che la codifica.

$redirectToLocation = urlencode(urlencode('/myothercontroller/action')); 
$this->openAndWait('/controller/action/thenRedirectTo/' . $redirectToLocation); 

Forse Apache lo decodificherà solo di un livello.

Answer 2

Ho riscontrato questo comportamento prima ed era mod_rewrite che stava eseguendo la decodifica. Per quanto ne so, l'unico modo per aggirare è urlencode la parte dell'URL di richiesta che deve conservare i caratteri speciali due volte.

Answer 3

Si dovrebbe impostare il mod_rewrite in modalità debug in Apache e guardare quello che fa:

RewriteEngine on 
RewriteLog /tmp/rewrite.log 
RewriteLogLevel 9 

e ci mostri il suo ZF riscrivere le regole. è certamente di base su% {QUERY_STRING} che è l'url decodificato in modo concorrente. Potremmo provare a rielaborarlo con% {THE_REQUEST}, che è l'url non decodificato. La cosa migliore sarebbe trattare% {THE_REQUEST} solo per il controller giusto.

Un'altra soluzione potrebbe essere utilizzando la codifica Base64 sull'URL, in modo che mod_rewrite e tutti gli altri strumenti non sarebbero mai prenderlo come informazioni URL.

Un'altra cosa da verificare è la [B] mod_rewrite, come spiegato qui: How to encode special characters using mod_rewrite & Apache?. Ma mi chiedo se non romperebbe la regola della riscrittura.

Answer 4

Sembra che questo Zend Framwork issue riguardi il tuo problema. Per verificare aprire Zend/Controller/Request/Http.php e rimuovere le chiamate della funzione urldecode ma mantenere le variabili in posizione e ripetere il test del codice.

Answer 5

Questa è una "funzione" di Apache. Le barre codificate vengono automaticamente decodificate e inviate all'applicazione (php). Pertanto è riconosciuto come un lungo uri invece di un uri con un uri codificato come parametro.

Tuttavia, è possibile disattivarlo, utilizzando AllowEncodedSlashes On nella configurazione. Maggiori informazioni allo Apache manual. Si prega di notare che il contesto di questa direttiva è configurazione del server e host virtuale, quindi non è possibile inserirlo in un file .htaccess.