Caracteres especiais no URL fazem com que o redirecionamento personalizado falhe

Question 1

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

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

Answer

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

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

Question 2

Tente mover os locais dos 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 instruída a sair antes de ser informada 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:

Ao usar [F], um [L] está implícito - ou seja, a resposta é retornada imediatamente e nenhuma outra regra é avaliada. 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. O que então envia a página para a página de erro padrão do Apache 403, uma vez que ela saiu antes de atingir essas declarações. Seu 404 funcionou porque nunca acionou nenhuma das regras que contém uma condição L, ou seja, última coisa a ser executada, e assim atingiu o final das regras do htaccess.

Nunca passei por essa situação porque sempre coloco as páginas de erro padrão no TOPO da diretiva, por hábito, junto com outras coisas essenciais, como ajustes de ini do php, etc.

As reescritas vão para baixo.

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

Acredito que isso esteja certo, mas não tenho 100% de certeza, pois sempre coloquei no topo as coisas que deveriam estar em cima e, portanto, nunca desencadeei o seu caso. A chave é perceber que L, Último, realmente significa Último, e então saber também que F implica L.

Em geral, vale a pena ser organizado ao lidar 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 nova linha/quebra de linha no final do seu arquivo .htaccess. Sua versão é extremamente aleatória e desorganizada, que é a verdadeira causa, na minha opinião, de seus problemas. Se você simplesmente se acostumar a ordenar suas regras de forma clara e consistente (ou seja, reescritas não são misturadas com outras regras), você descobrirá muito mais fácil trabalhar com o Apache em geral.

Answer