Utilice FallbackResource incluso si existe el directorio

He configurado mi host virtual en Apache 2.4.7 con una configuración muy básica:

<VirtualHost *:80>
  ServerName foo.example.com
  DocumentRoot /var/www/html

  DirectoryIndex index.php
  FallbackResource /index.php
</VirtualHost>

Debajo de la raíz del documento tengo la siguiente estructura:

/index.php
/help/readme.txt

Obtengo los siguientes resultados cuando hago solicitudes:

/bla     -> 200 OK
/help/   -> 404 Not Found
/help/a  -> 200 OK

Parece que la existencia del /help/directorio está causando que Apache regrese 404porque no hay index.phpallí, pero espero que todas las solicitudes se invoquen /index.phpy, por lo tanto, den una 200 OKrespuesta.

No recuerdo que esto sea un problema al usarlo mod_rewrite, pero prefiero usarlo FallbackResourcesi es posible. ¿Hay alguna manera de arreglar esto?

Actualizar

Funciona si elimino la DirectoryIndexdirectiva, pero eso tiene problemas de retraso de cinco segundos .

Actualización 3

Estoy ejecutando el siguiente entorno de prueba; La estructura del directorio es la siguiente:

./htdocs
   index.html
   test/
      bla.txt
./conf
   httpd.conf
./logs

El contenido de httpd.confes:

ServerName apache-bug.local
Listen 8085

DirectoryIndex disabled
DirectorySlash Off

<VirtualHost *:8085>
DocumentRoot /home/user/apache-bug/htdocs

FallbackResource /index.html
</VirtualHost>

Mi config.nicecontiene:

"./configure" \
"--enable-debugger-mode" \
"--with-apr=/usr/local/apr/bin/apr-1-config" \
"--enable-dir=static" \
"--with-mpm=prefork" \
"--enable-unixd=static" \
"--enable-authn-core=static" \
"--enable-authz-core=static" \
"$@"

Para ejecutar el servidor:

httpd -X -d /home/user/work/apache-bug/

También estoy respondiendo esto, porque estoy bastante seguro de que el problema está relacionado con el mod_dir.cfuncionamiento interno y creo que es un error .

Si un recurso no se puede asignar al sistema de archivos local, la función fixup_dflt()se ejecutará, usando FallbackResourcepara determinar qué documento debe cargarse en su lugar.

Sin embargo, cuando un recurso se puede asignar al sistema de archivos local y es un directorio, intentará resolver el documento ejecutándose fixup_dir(); Esta función itera sobre la lista de DirectoryIndexvalores hasta que encuentra el primer documento adecuado.

En mi caso, la configuración tiene una lista de DirectoryIndexvalores vacía , por fixup_dir()lo que fallará y se devolverá un 404.

El siguiente parche me funciona ( PR ):

static int dir_fixups(request_rec *r)
{
    if (r->finfo.filetype == APR_DIR) {
-        return fixup_dir(r);
+        if (fixup_dir(r) != OK) {
+           /* use fallback */
+           return fixup_dflt(r);
+        }
+
+        return OK;
    }
    else if ((r->finfo.filetype == APR_NOFILE) && (r->handler == NULL)) {
        /* No handler and nothing in the filesystem - use fallback */
        return fixup_dflt(r);
    }
    return DECLINED;
}

Básicamente lo intenta fixup_dflt()después de fixup_dir()fallar.

Actualizar 2015-04-21

Se ha enviado una solución al proyecto, programada para 2.5; puede ser portado a 2.4 también.

Actualizar 2015-05-18

La solución se ha revertido porque:

[...] [al menos] hace FallBackResourceque patear antes de que mod_autoindexpodría haber pateado.

Todavía estoy tratando de descubrir cómo evitar este tipo de situación.

Su configuración debe ser correcta.

El problema, por extraño que parezca, parece ser mod_deflate .

Después de haber reproducido su configuración con éxito aquí ( sin obtener un 404), también obtuve el retraso de 5 segundos. Sin embargo, noté que cuando el UA omite gzipde sus Encabezados de aceptación, la página se muestra / recibe instantáneamente. Puedes probar esto por ti mismo con wget.

Curiosamente, una mayor depuración stracemuestra que apache envía el contenido de su FallbackResourceal socket de su cliente sin una diferencia notable de retraso en ambos casos. Esto también es evidente en el cable, donde se envía un paquete de respuesta desde el servidor al cliente después de la solicitud HTTP sin ningún retraso notable ¹ .

Sin embargo, parece que cuando se usa mod_deflate en este caso, el UA no sabe cuándo finalizan los datos enviados por el servidor y, por lo tanto, no procesa nada antes de que la conexión TCP agote el tiempo ² y el servidor la cierre por la fuerza. Esto es compatible con HTTP / 1.0, donde una conexión cerrada significa el final del contenido.

Para HTTP / 1.1 , el servidor tiene otros medios disponibles para señalar el final del contenido , pero ninguno de los cuales parece suceder aquí .

Sin embargo, si el error acecha en mod_dir o mod_deflate, está más allá de mi tiempo disponible en este momento. Lo hice funcionar sin problemas al deshabilitar la compresión gzip; como solución alternativa hasta que el problema se solucione para siempre, puede deshabilitar selectivamente gzip.

¹ ) Esto nos dice que el problema no proviene de buffers no vacíos en el servidor.
² ) De manera predeterminada, el tiempo de espera es de 5 segundos con apache, de ahí provienen los 5 segundos.