Zend Framework: Apache descodifica la URL codificada en lugar de pasar la URL codificada.

Question

Estoy probando mi aplicación Zend Framework usando Selenium y PHPUnit. Tengo una prueba que necesita para abrir una URL que contiene una URL codificada.

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

Pero cuando corro mi prueba, el navegador intentado abrir la URL decodificada:

/controller/action/thenRedirectTo//myothercontroller/action 

¿Qué debo hacer para obtener el selenio para abrir la URL codificada?

Actualización: ... En realidad resulta que el selenio está haciendo su trabajo, pero parece como si Apache está decodificando la URL antes de que llegue al controlador:

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

Cómo debería solucionar este problema ?

Actualización: Aquí hay una conversación sobre el mismo problema que estoy teniendo: http://old.nabble.com/URL-Encoding-td18850769.html. Su solución fue codificar64 base64, pero eso no es lo suficientemente bueno para mí. Puedo usar esta solución a corto plazo, pero quiero saber cuál es la causa real de este problema, para poder eliminarlo.

Actualización: Tengo un compañero de trabajo que cree que puede haber un problema con la forma en Zend Framework es el enrutamiento de la petición. ¿Crees que podría ser el caso?

Answer 1

Problema interesante. Personalmente, nunca tuve problemas para pasar otra URL en una cadena de consulta, es decir,/controller/action/thenRedirectTo? Q =% 2Fmyothercontroller% 2Faction, pero no he usado Apache en mucho tiempo, y eso no es exactamente lo que tú ' Estoy tratando de hacer.

Una posible solución podría ser la codificación de doble URL.

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

Quizás Apache solo lo decodifique con url de un nivel.

Answer 2

Me he encontrado con este comportamiento antes y era mod_rewrite que estaba haciendo la decodificación. Por lo que yo sé, la única forma de evitarlo es urlencode, la parte de la URL de solicitud que necesita conservar caracteres especiales dos veces.

Answer 3

Se debe ajustar su mod_rewrite en modo de depuración en Apache y buscar en lo que hace:

RewriteEngine on 
RewriteLog /tmp/rewrite.log 
RewriteLogLevel 9 

y nos muestran su ZF reglas de reescritura. sin duda, está basado en% {QUERY_STRING}, que es la url decodificada de la competencia. Podríamos intentar volver a trabajar con% {THE_REQUEST}, que es la url no decodificada. Lo mejor sería tratar% {THE_REQUEST} solo para el controlador adecuado.

Otra solución podría ser la utilización de la codificación base64 en la url, de modo que mod_rewrite y otras herramientas nunca lo capten como información de la url.

Otra cosa para probar es la [B] en mod_rewrite, como se explica aquí: How to encode special characters using mod_rewrite & Apache?. Pero me pregunto si no rompería la regla de reescritura.

Answer 4

Parece que Zend Framwork issue se relaciona con su problema. Para verificar, abra Zend/Controller/Request/Http.php y elimine las llamadas a la función urldecode pero mantenga las variables en su lugar y vuelva a probar su código.

Answer 5

Esta es una "característica" de Apache. Las barras codificadas se decodifican automáticamente y se envían a la aplicación (php). Por lo tanto, se reconoce como un uri largo en lugar de un uri con un uri codificado como parámetro.

Sin embargo, es posible desactivarlo usando AllowEncodedSlashes On en su configuración. Más información en el Apache manual. Tenga en cuenta que el contexto de esta directiva es la configuración del servidor y el host virtual, por lo que no puede ubicarlo en un archivo .htaccess.