Servire Discourse da una sottocartella (prefisso percorso) invece che da un sottodominio

Da un po’ di tempo, notiamo che il container emette frequentemente messaggi X-Accel-Mapping header missing, anche se non per ogni visitatore o ogni passaggio di navigazione. Ho notato che questo header è definito esplicitamente nella configurazione di Nginx, sebbene non per tutte le richieste: discourse/config/nginx.sample.conf at main · discourse/discourse · GitHub

Poiché non vedo questo problema segnalato altrove in questo forum, mi chiedo se possa essere correlato alla configurazione in sottodirectory che utilizziamo, anche se non vedo come.

Non sono sicuro di cosa lo generi esattamente, ma suppongo che ciò accada solo se X-Sendfile-Type è impostato su X-Accel-Redirect, ma X-Accel-Mapping non è definito. La configurazione, però, definisce entrambi o li imposta entrambi vuoti :thinking:.

In realtà, viene impostato solo quando si accede ai backup e, cosa più rilevante, quando si accede ai file caricati. Ho appena testato e verificato che ogni volta che visualizzo un post con un’immagine caricata o simile, viene generato quel messaggio. Analizzando la configurazione, non dovrebbe essere possibile che X-Accel-Redirect sia impostato mentre X-Accel-Mapping no. Inoltre, si tratta di un header di richiesta impostato da Nginx all’interno del container, consumato esclusivamente da Discourse/unicorn/pitchfork/backend, quindi non entra né esce dal container.

Ah, abbiamo configurato Nginx per registrare gli errori su STDERR e, poiché non vedo questi messaggi nei log di Discourse, sono certo che sia Nginx stesso a generarli. Probabilmente è questo il motivo per cui non è stato notato da altri, dato che compare nel file di log di Nginx. Qualcuno ha tempo di verificare se anche il proprio shared/*/log/var-log/nginx/error.log contiene questi messaggi? Se sì, tornerò a confrontarmi con chi non utilizza una configurazione in sottodirectory per restringere il campo.