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/ .