Primero, este es un caso límite muy específico de mi configuración, con la subcarpeta /f.
El enlace de Discourse en el menú hamburguesa apunta a /faq, sin la subcarpeta, porque /faq comienza con /f.
Considerando esta cita:
Creo que podríamos cambiar
const found = url.startsWith(baseUri);
por algo como
const found = url === baseUri || url.startsWith(`${baseUri}/`);
De esta manera, coincidiría con /f, /f/, /f/faq, pero no con /faq, añadiendo correctamente el baseUri a este último.
De todos modos, la ruta en sí tampoco funciona; /f/faq devuelve un 404, así que creo que hay una lógica similar a nivel del enrutador. Anteriormente noté que /f/following tampoco funcionaba (cc @merefield).
Finalmente, cambié la configuración del sitio faq url a /f/guidelines como solución temporal, lo que corrigió el enlace y el error 404, pero generó una pequeña extrañeza: ahora aparecen tanto el término “Guidelines” como “FAQ” en la barra de navegación, ambos apuntando a lo establecido en faq url (puedes verificarlo en la página real):
He enviado un PR para abordar el problema de get-url:
Sobre el error 404 en /f/faq y /f/favicon/proxied, cuando ejecuto CURL en estas rutas dentro del contenedor, omitiendo Nginx, funciona. Logré solucionarlo cambiando la directiva location descrita en Serve Discourse from a subfolder (path prefix) instead of a subdomain de location /subfolder a location /subfolder/.
Que la barra de navegación muestre tanto Guidelines como FAQ es el comportamiento esperado; es poco probable que el usuario sobrescriba la faq url con la misma URL.
¿El problema de NGINX está resuelto con más documentación?