Erstens ist dies ein Randfall, der sehr spezifisch für meine Einrichtung mit dem Unterordner /f ist.
Der Discourse-Link zum Hamburger-Menü verweist auf /faq, ohne den Unterordner, da `/faq` mit `/f` beginnt`.
Angesichts dieses Zitats:
Ich schätze, wir könnten
const found = url.startsWith(baseUri);
zu etwas wie
const found = url === baseUri || url.startsWith(`${baseUri}/`);
ändern.
Dadurch würde es /f, /f/, /f/faq korrekt abgleichen, aber nicht /faq, wodurch baseUri korrekt an Letzteres angehängt wird.
Wie auch immer, die Route selbst funktioniert ebenfalls nicht; /f/faq liefert einen 404-Fehler, also gibt es meiner Meinung nach eine ähnliche Logik auf der Router-Ebene. Ich habe zuvor bemerkt, dass /f/following ebenfalls nicht funktionierte (cc @merefield).
Schließlich habe ich die faq url-Site-Einstellung als Workaround auf /f/guidelines geändert. Dies hat den Link und den 404-Fehler behoben, führte aber zu einer kleinen Unstimmigkeit: Sowohl die Begriffe „Guidelines“ als auch „FAQ“ erscheinen in der Navigationsleiste und verweisen beide auf das, was unter faq url eingestellt ist (Sie können dies auf der tatsächlichen Seite überprüfen):
Entschuldigen Sie diesen Themenmix mit drei Problemen, aber ich denke, sie sind so eng miteinander verknüpft, dass eine saubere Trennung schwierig wäre.
Ich habe einen PR gesendet, um das get-url-Problem zu beheben:
Bezüglich des 404-Fehlers auf /f/faq und /f/favicon/proxied: Wenn ich diese Routen im Container mit CURL aufrufe und Nginx umgehe, funktioniert es. Ich konnte das Problem beheben, indem ich die location-Direktive geändert habe, die unter Serve Discourse from a subfolder (path prefix) instead of a subdomain beschrieben ist, von location /subfolder zu location /subfolder/.
Dass die Navigationsleiste sowohl „Richtlinien“ als auch „FAQ“ anzeigt, ist das erwartete Verhalten. Es ist unwahrscheinlich, dass der Benutzer die faq url mit derselben URL überschreibt.
Ist das NGINX-Problem mit zusätzlichen Dokumentationen behoben?