2012-01-11 29 views
12

Hace varios días tuve una pregunta sobre la eliminación de index.php de la barra de direcciones, por lo que la dirección de la página parece más corta y mejor. La solución más corta de este problema fue (RewriteRule ^index.php/[L,R=301] in the .htaccess file). ¡Y funciona!Parece que los valores POST se pierden cuando se usa .htaccess RewriteRule. Los valores GET son correctos. ¿Como arreglar?

Desde que puse esa cadena en .htaccess, algunas páginas se redirigen a la página principal. Pasé mucho tiempo para adivinar, por qué. Según tengo entendido, la respuesta es: con RewriteRule ^index.php/[L,R=301], los parámetros $ _POST no se envían a la página siguiente. $ _GET parámetros están bien. Una vez que elimine RewriteRule ^index.php/[L,R=301] de .htaccess, todo se vuelve bien, como de costumbre. ¿Por qué ocurre y cómo solucionarlo?

Gracias.

+1

tiene el mismo problema con única bandera [L]. Esto ocurrió al cambiar el alojamiento, así que supongo que esto está, de alguna manera, relacionado con la configuración. – Tsadiq

+0

Aquí hay un buen enlace sobre la bandera [P] :) http://stackoverflow.com/questions/358263/htaccess-is-it-possible-to-redirect-post-data – Tsadiq

Respuesta

18

El indicador [R] incurrirá en una redirección. Y los usuarios-agentes emiten una redirección como solicitud GET. No se puede hacer nada si realmente desea acortar las URL hasta la ruta raíz /.

Se podría sin embargo bloquear las peticiones POST específicamente de ser reescrito/redirigida:

RewriteCond %{REQUEST_METHOD} !POST 
RewriteRule ^index.php/[L,R=301] 
4

Los valores POST NUNCA sobrevivirán a un redireccionamiento externo (el R=301), es una responsabilidad de seguridad, por lo que los navegadores nunca lo admitirán. Retire el R=301 y estará bien. Debería modificar todos los enlaces existentes a la página por uno más corto/más bonito (<a>, pero también por acciones, etc.)

+1

El [R = 301] romperá las solicitudes POST (datos de formulario perdidos), pero omitirlo no afectará a la barra de direcciones. Por esta razón, desearía evitar hacer este tipo de reescritura si (alguna vez) POSTING indexar. – Umbrella

+2

Sí. ¡Siempre se puede agregar un 'RewriteCond% {REQUEST_METHOD}!POST' antes de la reescritura, pero duda en pensar _por qué cualquier forma todavía tendría index.php como acción_ ... – Wrikken

+0

De hecho. Esa sería una buena pregunta para el OP. – Umbrella

5

estoy usando algo como:

<IfModule mod_rewrite.c> 

RewriteEngine on 

RewriteCond %{REQUEST_URI} !^/(css|images|js)/ 

# don't rewrite existing files, directories and links 

RewriteCond %{REQUEST_FILENAME} !-f 
RewriteCond %{REQUEST_FILENAME} !-d 
RewriteCond %{REQUEST_FILENAME} !-l 


# rewrite everything else to index.php 

RewriteRule .* index.php [L] 

</IfModule> 

Y su trabajo para todas las solicitudes, volver a escribir a través del índice. archivo php. Si necesita redirigir 301 (que significa código Movido permanentemente) echa un vistazo a esta pregunta: Is it possible to redirect post data?

+0

Esto parece un reemplazo al manejo 404 existente de apache. Más al punto, esto no parece abordar la pregunta. – Umbrella

10

Usted podría tratar de usar [L,R=307] lugar. 307 de no debe cambiar la solicitud-Procedimiento de acuerdo con la especificación, pero yo no sé qué navegador implementa 307.

Pero la raíz del problema es el uso de <form action="____/index.php" ...

Acaba de salir de la acción vacía a POST a la URL actual, por ejemplo

1

que tenía los mismos problemas pero mis htacces era así:

RewriteEngine on 
RewriteRule .* index.php [NC] 

Sólo cambia NC para L y todo funciona bien.

código final:

RewriteEngine on 
RewriteRule .* index.php [L] 
Cuestiones relacionadas