Quando você especifica apenas o diretório nulo, mod_dir emite uma subrequição interna para o DirectoryIndex (que eu suponho que esteja configurado para atender index.html
no seu caso). "O problema" é que a diretiva <Files>
é processada primeiro antes que a subrequência ocorra. Mas antes que essa subrequação ocorra, o nome do arquivo com o qual a diretiva <Files>
corresponde ainda não foi resolvido; ele está vazio! Então, precisamos corresponder a um nome de arquivo vazio .
No entanto, depois que a subrequisa de index.html
(o DirectoryIndex) ocorreu, o contêiner <Files>
é reprocessado (em um contexto .htaccess
), mas desta vez o nome do arquivo foi resolvido para index.html
. Então, precisamos combinar também com index.html
!
Isso pode ser contabilizado por ter dois contêineres <Files>
. Por exemplo:
<Files "">
Order allow,deny
Allow from all
</Files>
<Files "index.html">
Order allow,deny
Allow from all
</Files>
Ou (de preferência) combinando-os em um único contêiner <FilesMatch>
(que aceita um regex como argumento). Por exemplo:
<FilesMatch ^(index\.html)?$>
Order allow,deny
Allow from all
</Files>
Ao tornar o nome de arquivo opcional (% ?
), isso corresponde efetivamente a ambas as passagens: um nome de arquivo vazio e index.html
.
Se os URLs /
e /index.html
estiverem disponíveis e veicularem o mesmo conteúdo, você deverá canonicalizar o URL de alguma forma para evitar possíveis problemas de conteúdo duplicado. (De preferência, um redirecionamento de /index.html
para /
.)
...and type
www.example.com/path
Só para esclarecer, se o usuário digitar www.example.com/path
, onde path
é um diretório do sistema de arquivos e uma barra final é omitida da URL, então mod_dir (por padrão) emitirá uma saída externa 301 redireciona para www.example.com/path/
(com uma barra à direita) para "corrigir" o URL. Então, a URL com a qual estamos lidando é realmente www.example.com/path/
.