Verwenden Sie FallbackResource auch dann, wenn ein Verzeichnis vorhanden ist

Ich habe meinen virtuellen Host unter Apache 2.4.7 mit einer sehr einfachen Konfiguration eingerichtet:

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

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

Unter dem Dokumentenstamm habe ich folgende Struktur:

/index.php
/help/readme.txt

Ich erhalte die folgenden Ergebnisse, wenn ich Anfragen stelle:

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

Es scheint, dass die Existenz des /help/Verzeichnisses dazu führt, dass Apache zurückkehrt, 404weil dort kein index.phpvorhanden ist, aber ich erwarte, dass alle Anforderungen aufgerufen werden /index.phpund somit eine 200 OKAntwort erhalten.

Ich erinnere mich nicht, dass dies ein Problem bei der Verwendung war mod_rewrite, aber ich bevorzuge die Verwendung, FallbackResourcewenn möglich. Gibt es eine Möglichkeit, dies zu beheben?

Aktualisieren

Es funktioniert, wenn ich die DirectoryIndexDirektive entferne , aber das leidet unter fünf Sekunden Verzögerung .

Update 3

Ich führe die folgende Testumgebung aus. Die Verzeichnisstruktur lautet wie folgt:

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

Der Inhalt von httpd.confist:

ServerName apache-bug.local
Listen 8085

DirectoryIndex disabled
DirectorySlash Off

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

FallbackResource /index.html
</VirtualHost>

Mein config.niceenthält:

"./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" \
"$@"

So führen Sie den Server aus:

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

Ich beantworte dies auch selbst, da ich ziemlich sicher bin, dass das Problem damit zusammenhängt, wie es internmod_dir.c funktioniert, und ich denke, dass es ein Fehler ist .

Wenn eine Ressource nicht dem lokalen Dateisystem zugeordnet werden kann, wird die Funktion fixup_dflt()ausgeführt, wobei FallbackResourcebestimmt wird, welches Dokument stattdessen geladen werden soll.

Wenn jedoch eine Ressource kann auf das lokale Dateisystem abgebildet werden und es ist ein Verzeichnis, wird versucht, das Dokument zu lösen , indem Sie fixup_dir(); Diese Funktion durchläuft die Werteliste DirectoryIndex, bis das erste geeignete Dokument gefunden wird.

In meinem Fall hat die Konfiguration eine leere DirectoryIndexWerteliste, fixup_dir()schlägt also fehl und ein 404 wird zurückgegeben.

Der folgende Patch funktioniert für mich ( 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;
}

Es versucht im Grunde fixup_dflt()nach fixup_dir()fehlgeschlagen.

Update 2015-04-21

Für das Projekt wurde ein Fix eingereicht, der für 2.5 geplant ist. Es kann auch auf 2.4 portiert werden.

Update 2015-05-18

Das Update wurde zurückgesetzt, weil:

[...] es [zumindest] veranlasst FallBackResource, einzutreten, bevor mod_autoindexes eingetreten sein könnte.

Ich versuche immer noch herauszufinden, wie ich diese Art von Situation vermeiden kann.

Ihre Konfiguration sollte korrekt sein.

Das Problem scheint seltsamerweise mod_deflate zu sein .

Nachdem ich Ihre Konfiguration hier erfolgreich reproduziert habe ( keine 404), habe ich auch die Verzögerung von 5 Sekunden erhalten. Ich habe jedoch festgestellt, dass gzipdie Seite sofort angezeigt / empfangen wird , wenn der UA in seinen Accept-Headern nicht angezeigt wird. Sie können dies selbst testen wget.

Interessanterweise zeigt ein weiteres Debugging mit strace, dass Apache den Inhalt von Ihnen FallbackResourcein beiden Fällen ohne merklichen Unterschied in der Verzögerung an den Socket Ihres Clients sendet . Dies zeigt sich auch auf der Leitung, auf der nach der HTTP-Anforderung ohne nennenswerte Verzögerung ¹ ein Antwortpaket vom Server an den Client gesendet wird ¹ .

Bei Verwendung von mod_deflate in diesem Fall scheint der UA jedoch nicht zu wissen, wann die vom Server gesendeten Daten enden, und rendert daher nichts, bevor die TCP-Verbindung abläuft ² und vom Server zwangsweise geschlossen wird. Dies ist kompatibel mit HTTP / 1.0, wobei eine geschlossene Verbindung das Ende des Inhalts anzeigt.

Für HTTP / 1.1 stehen dem Server andere Mittel zur Verfügung, um das Ende des Inhalts zu signalisieren - aber keines davon scheint hier zu passieren .

Ob der Fehler jedoch in mod_dir oder mod_deflate lauert, ist momentan nicht mehr verfügbar. Ich habe es einwandfrei funktionieren lassen, indem ich die gzip-Komprimierung deaktiviert habe. Um dieses Problem zu umgehen, bis das Problem endgültig behoben ist, können Sie gzip selektiv deaktivieren.

¹ ) Dies sagt uns, dass das Problem nicht von nicht geleerten Puffern auf dem Server herrührt.
² ) Standardmäßig beträgt das Zeitlimit bei Apache 5 Sekunden - von dort stammen Ihre 5 Sekunden.