Caracteres especiais em URL fazem com que o redirecionamento personalizado falhe

Question

Eu tenho um domínio no qual estou tentando definir redirecionamentos personalizados para as páginas de erro.
Meu arquivo .htaccess parece assim:

RewriteEngine On
AddDefaultCharset UTF-8
DefaultLanguage en-US
# disable TRACK and TRACE http methods. 'RewriteEngine On' is required!
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK|OPTIONS|HEAD|PUT|DELETE)
RewriteRule .* - [F]
Options All -Indexes
ServerSignature Off
<ifModule mod_headers.c>
        Header unset X-Powered-By
</ifModule>
<Files .htaccess>
order allow,deny
deny from all
</Files>
<IfModule php5_module>
        php_value session.cookie_httponly true
        #php_value session.cookie_secure true
</IfModule>
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]

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


#Error page handeller
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

Quando digito algo no URL da seguinte forma:

• example.com/aboutUs : tudo funciona normalmente.
• example.com/xxygsds : o URL é redirecionado para a página de erro 404 personalizada.
• example.com/<> : isso redireciona para a página 403 proibida. No entanto, o redirecionamento é para a página apache/error/HTTP_FORBIDDEN.html.var e não para a página personalizada, conforme mencionado acima.

Minhas perguntas:
1. Por que esse redirecionamento está acontecendo?
2. Como posso redirecioná-lo para a página de erro 403 customizada em todas as condições?

    

Answer 1

Não sei por que isso acontece. Tenho o mesmo problema com a minha página 403. Se você quiser redirecionar uma página 403 específica, use isto:

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

    

Answer 2

Tente mover os locais dos seus documentos de erro para o TOPO do seu arquivo .htaccess. Eu olhei para o seu exemplo por um tempo tentando descobrir o que estava acontecendo, então finalmente percebi que a coisa está sendo dito para sair antes que seja dito para onde sair neste caso.

O Apache está lendo as diretivas em ordem e sai no caso L. O L está implícito em F:

When using [F], an [L] is implied - that is, the response is returned immediately, and no further rules are evaluated. https://httpd.apache.org/docs/2.4/rewrite/flags.html

Então, estou supondo que o apache simplesmente nunca chega a esse conjunto de instruções quando atinge o caso verdadeiro e correspondente do seu < > exemplo. Em seguida, envia a página para a página de erro padrão do apache 403, uma vez que ela saiu antes de chegar a essas declarações. Seu 404 funcionou porque nunca acionou nenhuma das regras que contêm uma condição L, ou seja, a última coisa a executar, e assim alcançou a parte inferior das regras de htaccess.

Eu nunca cheguei nessa situação, porque eu sempre coloco as páginas de erro padrão no TOP da diretiva, por hábito, junto com outras coisas essenciais, como ajustes do php ini, etc.

As reescritas vão para o fundo.

O objetivo é que tudo que você queria dizer ao apache foi informado para o apache no momento em que ele atinge o caso L para uma reescrita ou o fim das regras htacess / config. Se não fosse o htaccess, o apache teria conhecido todas as regras quando começou a servir o seu site, mas com o htacess, acredito que apenas as lê e faz o que o arquivo diz.

Eu acredito que isso é certo, mas eu não tenho 100% de certeza, já que eu sempre coloco as coisas que deveriam estar no topo e, assim, nunca acionei o seu caso. A chave é perceber que L, Last, realmente significa Last, e então saber também que F implica L.

Em geral, vale a pena ser organizado quando se lida com configurações do 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]

Lembre-se de adicionar sempre uma quebra de linha / nova linha no final do seu arquivo .htaccess. Sua versão é extremamente aleatória e desorganizada, o que é a causa real em minha opinião de seus problemas, se você simplesmente se acostumar a ordenar suas regras de forma clara e consistente (ou seja, as reescritas não estão misturadas com outras regras), você encontrará muito mais fácil trabalhar com o apache em geral.