RewriteCond en .htaccess con la condición de expresión regular negada no funciona?

Question

Estoy tratando de evitar, en este caso WordPress, reescribir ciertas URL. En este caso, estoy tratando de evitar que maneje una solicitud en el directorio de carga y, en cambio, los dejo en la página 404 del servidor. Así que estoy asumiendo que es tan simple como añadir la regla:

RewriteCond %{REQUEST_URI} !^/wp-content/uploads/ 

Esta regla debería evaluar en falso y hacer que la cadena de reglas fallan por esas peticiones, deteniendo así la reescritura. Pero no ... ¿Quizás necesito unir la tapa con la cuerda completa en mi expresión?

RewriteCond %{REQUEST_URI} !^/wp-content/uploads/.*$ 

No, eso tampoco lo es. Entonces, después de rascarme la cabeza, hago un chequeo de cordura. Quizás algo está mal con el patrón real. Así que hago un caso de prueba simple.

RewriteCond %{REQUEST_URI} ^/xyz/$ 

En este caso, la reescritura sucede si y sólo si la URL solicitada es/xyz/y muestra la página del servidor 404 por cualquier otra página. Esto es exactamente lo que esperaba. ¡Así que me quedaré con un! para negar ese patrón.

RewriteCond %{REQUEST_URI} !^/xyz/$ 

Ahora estoy esperando ver exactamente lo contrario de la condición anterior. La reescritura no debería ocurrir para/xyz/sino para cualquier otra URL posible. En cambio, la reescritura ocurre para cada URL, ambos/xyz/y otros.

Por lo tanto, o el uso de expresiones regulares negadas en RewriteConds está roto en Apache, o hay algo fundamental que no entiendo al respecto. ¿Cuál es?

El servidor es Apache2.

El archivo en su totalidad: archivo predeterminado

<IfModule mod_rewrite.c> 
RewriteEngine On 

RewriteBase/
RewriteRule ^index\.php$ - [L] 

RewriteCond %{REQUEST_FILENAME} !-f 
RewriteCond %{REQUEST_FILENAME} !-d 
RewriteCond %{REQUEST_URI} !^/wp-content/uploads/ 
RewriteRule . /index.php [L] 
</IfModule> 

de WordPress más mi regla.

Answer 1

Entonces, después de mucha irritación, descubrí el problema, más o menos. Resultó que la regla en mi pregunta original realmente hizo exactamente lo que se suponía que debía hacer.Lo mismo hizo una serie de otras formas de hacer lo mismo, como

RewriteRule ^wp-content/uploads/.*$ - [L] 

(Marcos regla cuya última si el patrón coincide) o

RewriteRule ^wp-content/uploads/.*$ - [S=1] 

(Saltar la siguiente regla si el patrón coincide), así como la regla negada en la pregunta, como se mencionó. Todas esas reglas funcionaron bien y devolvieron el control a Apache sin reescribir.

El problema ocurrió después de que se procesaron esas reglas. En cambio, el problema fue que eliminé las plantillas predeterminadas 404.shtml, 403.shtml etc. que mi host proporcionó. Si no tiene ninguna reescritura de .htaccess, eso funciona bien; el servidor desplegará su propia página 404 predeterminada y todo funciona. (Al menos eso es lo que pensé, pero en realidad fue el doble error "Además, se encontró un error 404 No encontrado al intentar usar un ErrorDocument para manejar la solicitud.")

Cuando usted tiene un. htaccess, por otro lado, se ejecuta por segunda vez para la página 404. Si la página está allí, se usará, pero ahora, en cambio, la solicitud de 404.shtml fue capturada por la regla catch-all y reescrita en index.php. Por esta razón, todas las demás sugerencias que he recibido aquí, o en otro lugar, han fallado porque al final la página 404 se ha reescrito en index.php.

Entonces, la solución fue simplemente restaurar las plantillas de error. En retrospectiva, fue bastante estúpido eliminarlos, pero tengo esta mentalidad de "empezar desde cero". No quiero nada aparentemente innecesario por ahí. Al menos ahora entiendo lo que estaba pasando, que es lo que quería.

Finalmente un comentario para Cecil: Nunca quise prohibir el acceso a nada, simplemente detuve la reescritura. No es que importe mucho ahora, pero solo quería aclarar esto.

Answer 2

<IfModule mod_rewrite.c> 
RewriteEngine On 

RewriteBase/
RewriteRule ^index\.php$ - [L] 

RewriteCond %{REQUEST_URI} !^/wp-content/uploads/ [OR] 
RewriteCond %{REQUEST_FILENAME} !-f 
RewriteCond %{REQUEST_FILENAME} !-d 

RewriteRule . /index.php [L] 
</IfModule> 

Answer 3

Si /wp-content/uploads/ es realmente el prefijo de la ruta URI solicitado, se suponía que su regla para funcionar como se espera.

Pero como obviamente no funciona, intente no hacer coincidir el prefijo de ruta de la ruta completa de URI pero solo la ruta restante sin el prefijo de ruta de acceso contextual por directorio, en el caso del archivo .htaccess en la raíz del documento directorio de la ruta de URI sin anteponer /:

RewriteCond $0 !^wp-content/uploads/ 
RewriteCond %{REQUEST_FILENAME} !-f 
RewriteCond %{REQUEST_FILENAME} !-d 
RewriteRule .+ /index.php [L] 

Si eso no funciona tampoco, que sin duda ayudaría a obtener una idea de proceso de reescritura de mod_rewrite utilizando su logging feature. Configure RewriteLogLevel a un nivel de al menos 4, realice su solicitud y observe las entradas en el archivo de registro especificado con RewriteLog. Allí puede ver cómo mod_rewrite maneja su solicitud y con RewriteLogLevel mayor o igual a 4 también verá los valores de variables como %{REQUEST_URI}.