problema de mod_rewrite con la ruta relativa css/js

Question

Hola, tengo un problema. Quiero obtener todas las solicitudes para redirigir al archivo de índice en el directorio principal y lo he logrado, pero hay problemas con las rutas de acceso relativas.
Cuando pongo una dirección como: midominio.com/ algo, funciona bien ya que las rutas son relativas al directorio principal.
El problema es cuando pongo algo como: midominio.com/something/somethingelse.

el archivo .htaccess:

Options FollowSymLinks 
RewriteEngine On 
# ignore anything that's an actual file 
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f 
# redirect all other traffic to the index page 
RewriteRule . index.php [L] 

¿Alguna idea sobre cómo conseguir css/js de trabajo?

---

Editar:

El problema es que los archivos css/js no se cargan cuando la ruta introducida tiene múltiples barras
como: mydomain.com/something/somethingelse

Answer 1

Es sin duda mejor utilizar la ruta absoluta para archivos estáticos (css, js, imágenes, etc.). Pero si tiene muchas de esas instancias en varias páginas, considere usar HTML base tag para especificar una URL predeterminada para rutas relativas. por ejemplo:

<base href="http://www.example.com/static/" /> 

Answer 2

RewriteCond %{REQUEST_FILENAME} !-f 
RewriteRule . index.php [L] 

En caso Obviamente funcionan a pesar de los comentarios.

Intente agregar la directiva RewriteLog y RewriteLogLevel para darnos mejores detalles.

Answer 3

Este es un problema de resolución de ruta: Al utilizar la ruta relativa ./css en la ruta de la base /something se acuerda /css mientras que en /something/somethingelse se acuerda /something/css.

Esto no puede (o más bien no debería ser) corregido con mod_rewrite. Utilice rutas absolutas en lugar de rutas relativas, por lo que /css en lugar de ./css.

Answer 4

Utilizando el -tag <base> es una buena solución y la mayoría de los navegadores parece manejarlo bien. Excepto que hay algunos problemas con IE, como era de esperar ... Aparentemente también puede encontrarse con otros problemas divertidos, see discussion here.

Así que para las personas donde esto no es una opción, he buscado en la alternativa (la "manera difícil").

Por lo general se almacenan css/js/imágenes estáticas/otras cosas como esta:

index.php 
js/ 
css/ 
imgs/ 

y desea que el javascript y hojas de estilo, etc. a estar disponible, no importa cuántas rayas verticales que hay en la url. Si su URL es /site/action/user/new entonces su navegador solicitará

/site/action/user/css/style.css 
/site/action/user/css/framework/fonts/icons.ttf 
/site/action/user/js/page.js 
/site/action/user/js/jquery/jquery.min.js 
/site/action/user/js/some/library/with/deep/dir/structure/file.map 

Así que aquí hay algunas reglas de reescritura de Apache para resolver este ...En primer lugar, si el destino existe realmente en el disco, no volver a escribir:

RewriteCond %{REQUEST_FILENAME} -d [OR] 
RewriteCond %{REQUEST_FILENAME} -f 
RewriteRule ^.*$ - [L,QSA] 

En palabras, si el nombre de archivo reqest es un directorio o si la solicitud de nombre de archivo es un archivo entonces no volver a escribir (-), última regla (L) y pase cualquier parámetro GET (QSA, apéndice de cadena de consulta). También puede usar

RewriteCond %{REQUEST_FILENAME} -d [OR] 
RewriteCond %{REQUEST_FILENAME} -f [OR] 
RewriteCond %{REQUEST_FILENAME} -l 
RewriteRule ^.*$ - [L,QSA] 

si también necesita enlaces simbólicos. A continuación, queremos que se encuentren javascript y las hojas de estilo, incluso si las solicitudes suponen un directorio base incorrecto, como se muestra arriba.

RewriteRule ^.*/js/(.*)$ js/$1 [L]  
RewriteRule ^.*/css/(.*)$ css/$1 [L] 

El patrón es bastante obvio, simplemente reemplace 'css' con el nombre del directorio. Todavía hay un problema con esto, especialmente para sitios web grandes con muchos javascript y hojas de estilo, bibliotecas, etc. - La expresión regular es codiciosa. Por ejemplo, si usted tiene un directorio javascript así:

js/some/library/js/script.js 

y su solicitud va a /site/action/user/new, el navegador solicitará /site/action/user/new/js/some/library/js/script.js, que la reescritura del motor se vuelva a grabar a

js/script.js 

porque el primero .* es codicioso y coincide con /site/action/user/new/js/some/library. Cambiar a regex no codicioso realmente no tiene sentido, ya que "the rewrite engine repeats all the rules until the URI is the same before and after an iteration through the rules."

Hay otro problema, y ​​es que para cada directorio que necesita estar exento de reescritura, se necesita una expresión regular relativamente "costosa". Ambos problemas pueden solucionarse simplemente colocando cada componente estático en un subdirectorio con un nombre "inusual" (y realmente esta es la mejor solución para todos: cualquiera que tenga una mejor idea, por favor publíquela).

La estructura de directorios sería el siguiente aspecto:

index.php 
mystrangedir/js/ 
mystrangedir/css/ 
mystrangedir/imgs/ 

Por supuesto, esto tiene que ser insertado en cualquier parte del código - para proyectos con una gran base de código existente esto puede ser complicado. Sin embargo, sólo se necesita una única expresión regular para la exención de directorio a continuación:

RewriteRule ^.*/mystrangedir/(.*)$ mystrangedir/$1 [L] 

automatizado construir sistemas (como el trago, ronco ....) se puede utilizar para comprobar si "mystrangedir" no existe como directorio en cualquier lugar por debajo de sí mismo (lo que arrojaría de nuevo el motor de reescritura).

Siéntase libre de cambiar el nombre de mystrangedir a algo más sensible como static_content pero cuanto más sensible se vuelve, más probable es que el nombre del directorio ya se utilice en alguna biblioteca. Si desea un nombre de directorio absolutamente seguro que nunca se haya utilizado antes, use un hash criptográfico, p. 010f8cea4cd34f820a9a01cb3446cb93637a54d840a4f3c106d1d41b030c7bcb. Esto es bastante largo para que coincida; puede hacer una compensación entre la unicidad y el rendimiento regex al acortarlo.