Utilizzare FallbackResource anche se esiste una directory

Ho impostato il mio host virtuale su Apache 2.4.7 con una configurazione molto semplice:

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

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

Sotto la radice del documento ho la seguente struttura:

/index.php
/help/readme.txt

Ottengo i seguenti risultati quando faccio le richieste:

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

Sembra che l'esistenza della /help/directory stia causando la restituzione di Apache 404perché non c'è index.phpdentro, ma mi aspetto che tutte le richieste vengano invocate /index.phpe quindi producano una 200 OKrisposta.

Non ricordo che questo sia un problema durante l'utilizzo mod_rewrite, ma preferisco usare FallbackResourcese possibile. C'è un modo per risolvere questo problema?

Aggiornare

Funziona se rimuovo la DirectoryIndexdirettiva, ma soffre di problemi di ritardo di cinque secondi .

Aggiornamento 3

Sto eseguendo il seguente ambiente di test; la struttura delle directory è la seguente:

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

Il contenuto di httpd.confè:

ServerName apache-bug.local
Listen 8085

DirectoryIndex disabled
DirectorySlash Off

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

FallbackResource /index.html
</VirtualHost>

Il mio 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" \
"$@"

Per eseguire il server:

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

Sto rispondendo anche a me stesso, perché sono abbastanza sicuro che il problema sia correlato a come mod_dir.cfunziona internamente e penso che sia un bug .

Se una risorsa non può essere mappata al file system locale, la funzione fixup_dflt()verrà eseguita, usando invece FallbackResourceper determinare quale documento deve essere caricato.

Tuttavia, quando una risorsa può essere mappata sul file system locale ed è una directory, tenterà di risolvere il documento eseguendo fixup_dir(); questa funzione scorre sull'elenco dei DirectoryIndexvalori fino a quando non trova il primo documento adatto.

Nel mio caso, la configurazione ha un elenco vuoto di DirectoryIndexvalori, quindi fixup_dir()fallirà e verrà restituito un 404.

La seguente patch funziona per me ( 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;
}

Praticamente prova fixup_dflt()dopo fixup_dir()fallito.

Aggiornamento 21/04/2015

È stata inviata una correzione al progetto, prevista per 2.5; può essere portato anche su 2.4.

Aggiornamento 18/05/2015

La correzione è stata ripristinata perché:

[...] [almeno] provoca il FallBackResourcecalcio d'inizio prima che mod_autoindexpossa essere entrato.

Sto ancora cercando di capire come evitare questo tipo di situazione.

La tua configurazione dovrebbe essere corretta.

Il problema, stranamente, sembra essere mod_deflate .

Dopo aver riprodotto correttamente la tua configurazione qui ( non ottenendo un 404), ho anche ottenuto il ritardo di 5 secondi. Tuttavia, ho notato che quando l'UA omette gzipdalle sue Accetta-Header, la pagina viene visualizzata / ricevuta istantaneamente. Puoi provarlo tu stesso con wget.

È interessante notare che un ulteriore debug con stracemostra che Apache invia il contenuto del tuo FallbackResourceal socket del tuo client senza notevoli differenze di ritardo in entrambi i casi. Ciò è evidente anche sul filo, in cui un pacchetto di risposta viene inviato dal server al client dopo la richiesta HTTP senza alcun notevole ritardo ¹ .

Sembra che quando si utilizza mod_deflate in questo caso, UA non sappia quando terminano i dati inviati dal server, quindi non esegue il rendering di alcunché prima che la connessione TCP scada ² e viene forzatamente chiuso dal server. Questo è conforme a HTTP / 1.0, in cui una connessione chiusa indica la fine del contenuto.

Per HTTP / 1.1 , il server ha altri mezzi disponibili per segnalare la fine del contenuto , ma nessuno dei quali sembra accadere qui .

Se il bug si nasconde in mod_dir o mod_deflate, tuttavia, è al di là del mio tempo disponibile in questo momento. L'ho fatto funzionare perfettamente disabilitando la compressione gzip; come soluzione alternativa fino a quando il problema non viene risolto definitivamente, puoi disabilitare selettivamente gzip.

¹ ) Questo ci dice che il problema non deriva da buffer non scaricati sul server.
² ) Per impostazione predefinita, il timeout è di 5 secondi con apache: ecco da dove provengono i tuoi 5 secondi.