Los caracteres especiales en la URL provocan que falle el redireccionamiento personalizado

Question 1

No estoy seguro de por qué hace eso. Tengo el mismo problema con mi página 403. Si desea redirigir una página 403 específica, utilice esto:

<Files some_thing> 
order Deny,Allow 
Deny from all 
</Files>

Answer

No estoy seguro de por qué hace eso. Tengo el mismo problema con mi página 403. Si desea redirigir una página 403 específica, utilice esto:

<Files some_thing> 
order Deny,Allow 
Deny from all 
</Files>

Question 2

Intente mover las ubicaciones de sus documentos de error a la PARTE SUPERIOR de su archivo .htaccess. Miré su ejemplo por un tiempo tratando de descubrir qué estaba sucediendo, luego finalmente me di cuenta de que en este caso se le dice a la cosa que salga antes de saber por dónde salir.

Apache está leyendo las directivas en orden y sale en el caso L. La L está implícita en F:

Cuando se utiliza [F], se implica una [L], es decir, la respuesta se devuelve inmediatamente y no se evalúan más reglas. https://httpd.apache.org/docs/2.4/rewrite/flags.html

Así que supongo que Apache simplemente nunca llega a ese conjunto de instrucciones cuando llega al caso verdadero y coincidente de su ejemplo <>. Lo que luego envía la página a la página de error 403 predeterminada de Apache, ya que salió antes de llegar a esas declaraciones. Su 404 funcionó porque nunca activó ninguna de las reglas que contienen una condición L, es decir, lo último en ejecutarse, por lo que llegó al final de las reglas de htaccess.

Nunca me he encontrado con esta situación porque siempre coloco las páginas de error predeterminadas en la parte SUPERIOR de la directiva, por costumbre, junto con otras cosas principales como ajustes de php ini, etc.

Las reescrituras van al final.

El objetivo es que todo lo que quería decirle a Apache se le haya dicho a Apache cuando llegue al caso L para una reescritura, o al final de las reglas htacess/config. Si no fuera htaccess, Apache habría conocido todas las reglas cuando comenzó a servir su sitio, pero con htaccess, creo que simplemente las lee y hace lo que le indica el archivo.

Creo que esto es correcto, pero no estoy 100% seguro, ya que siempre puse las cosas que deberían estar en la parte superior y, por lo tanto, nunca desencadené su caso. La clave es darse cuenta de que L, Último, realmente significa Último, y luego saber también que F implica L.

En general, vale la pena estar organizado cuando se trata de configuraciones de Apache:

# top generics etc
#Error page handler
ErrorDocument 400 /htaccessSample/errordocs/error-code.php
ErrorDocument 401 /htaccessSample/errordocs/error-code.php
ErrorDocument 403 /htaccessSample/errordocs/error-code.php
ErrorDocument 404 /htaccessSample/errordocs/error-code.php

AddDefaultCharset UTF-8
DefaultLanguage en-US
# Disable Directory Browsing, not related to rewrite
Options All -Indexes

# Secure directories by disabling execution of scripts
AddHandler .php .pl .py .jsp .asp .htm .shtml .sh .cgi
Options -ExecCGI

ServerSignature Off
<ifModule mod_headers.c>
        Header unset X-Powered-By
</ifModule>

<IfModule php5_module>
        php_value session.cookie_httponly true
        #php_value session.cookie_secure true
</IfModule>

<Files .htaccess>
order allow,deny
deny from all
</Files>

## NOW do the set of rewrite rules, everything that apache needs to 
## know has been told to it by this point
RewriteEngine On
# disable TRACK and TRACE http methods. 'RewriteEngine On' is required!
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK|OPTIONS|HEAD|PUT|DELETE)
RewriteRule .* - [F]

RewriteCond %{QUERY_STRING} _escaped_fragment_=(.*)
#to block all links to '.gif', '.jpg','.js' and '.css'  files which are not from the domain name 'http://www.example.com/'
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?example.com/.*$ [NC]
RewriteRule \.(gif|jpg|css|js)$ - [F]
#to deny requests containing invalid characters
RewriteBase /
RewriteCond %{THE_REQUEST} !^[A-Z]{3,9}\ [a-zA-Z0-9\.\+_/\-\?\=\&]+\ HTTP/ [NC]
RewriteRule .* - [F,NS,L]

Recuerde agregar siempre una nueva línea/salto de línea al final de su archivo .htaccess. Su versión es extremadamente aleatoria y desorganizada, que es la causa real, en mi opinión, de sus problemas. Si simplemente se acostumbra a ordenar sus reglas de manera clara y consistente (es decir, las reescrituras no se mezclan con otras reglas), lo encontrará. Es mucho más fácil trabajar con Apache en general.

Answer