Seit einiger Zeit sehen wir sehr häufig die Meldung X-Accel-Mapping header missing, die vom Container ausgegeben wird, allerdings nicht bei jedem Besucher oder jedem Navigationsschritt. Ich sehe, dass dieser Header zwar in der Nginx-Konfiguration explizit definiert ist, jedoch nicht für alle Anfragen: discourse/config/nginx.sample.conf at main · discourse/discourse · GitHub
Da ich dies nirgendwo sonst in diesem Forum berichtet sehe, frage ich mich, ob es mit unserer Subdirectory-Konfiguration zusammenhängen könnte, obwohl ich nicht genau verstehe, wie.
Ich bin mir nicht sicher, was genau diese Meldung ausgibt, aber ich vermute, dass dies nur dann passieren sollte, wenn X-Sendfile-Type auf X-Accel-Redirect gesetzt ist, X-Accel-Mapping jedoch nicht gesetzt ist. Die Konfiguration definiert jedoch beides oder setzt beides leer
.
Tatsächlich wird dies nur beim Zugriff auf Backups und, relevanter, beim Zugriff auf Uploads gesetzt. Ich habe gerade getestet und bestätigt, dass diese Meldung immer ausgelöst wird, wenn ich einen Beitrag mit einem hochgeladenen Bild oder Ähnlichem ansehe. Bei Betrachtung der Konfiguration sollte es unmöglich sein, dass X-Accel-Redirect gesetzt ist, aber X-Accel-Mapping nicht. Außerdem handelt es sich hierbei um einen Request-Header, der von Nginx innerhalb des Containers gesetzt und ausschließlich von Discourse/Unicorn/Pitchfork/Backend konsumiert wird; er tritt also weder in den Container ein noch verlässt er ihn.
Ah, wir konfigurieren Nginx so, dass es in STDERR protokolliert wird, und da ich dies nicht in den Discourse-Logs sehe, bin ich mir sicher, dass Nginx selbst diese Meldung ausgibt. Das ist wahrscheinlich der Grund, warum dies von niemandem sonst bemerkt wurde, da es in der Nginx-Logdatei steht. Hat jemand Zeit zu prüfen, ob auch bei ihnen shared/*/log/var-log/nginx/error.log diese Meldungen enthält? Falls ja, würde ich mich mit anderen, die kein Subdirectory-Setup verwenden, abstimmen, um die Ursache einzugrenzen.