Redirection vers le conteneur Discourse avec proxy_pass nginx et liens de Discourse vers le serveur hôte

Bonjour l’équipe Discourse,

Je fais tourner un serveur nginx sur ma machine hôte et un conteneur Discourse assez standard dans Docker. En gros, j’ai un petit nombre de dossiers spécifiques (http) servis par nginx sur l’hôte, et tout le reste est transféré vers le conteneur Discourse via proxy_pass.

Pour comprendre le problème, il suffit de savoir que mon fichier de configuration nginx sur l’hôte définit un emplacement /xyz, géré par nginx sur l’hôte, puis un emplacement / qui est défini pour être proxy_passé vers le conteneur Discourse.

Pour mon cas d’usage, je dois publier des liens en tant que messages Discourse pointant vers my.domaiin.com/xyz/some.html, c’est-à-dire que les liens à l’intérieur de Discourse pointent vers des pages servies par nginx sur l’hôte.

Cela fonctionnait jusqu’à la dernière mise à jour de Discourse. Maintenant, cliquer sur les liens aboutit à la page Discourse « impossible de trouver… ». En revanche, copier les cibles des liens et les ouvrir dans un nouvel onglet fonctionne comme prévu.

Je possède une bonne compréhension des protocoles de bas niveau, mais plus on monte dans la pile protocolaire, moins je connais :wink:
Mon hypothèse actuelle est que Discourse nginx maintient la connexion ouverte (keepalive ?), de sorte que nginx sur l’hôte rate l’opportunité d’analyser le nouveau chemin de requête pour sélectionner le bon serveur. Les requêtes de la connexion sont transmises au conteneur tel quel et restent actives. Ensuite, la requête pour le chemin /xyz est répondue par Discourse, qui ne connaît pas ce dossier..

Comment devrais-je aborder ce problème ? S’il n’y a pas de solution simple, il serait déjà utile d’obtenir quelques pistes, même une bonne description par rapport à une connaissance décente du protocole HTTP pourrait aider.

Merci !

Note complémentaire : Si cela concerne vraiment un problème de keep-alive, je suis tout à fait d’accord pour désactiver le keep-alive et accepter une certaine surcharge de coûts. Cette installation n’est pas destinée à servir un grand nombre d’utilisateurs.

En y réfléchissant, je devrai probablement configurer le hôte nginx pour qu’il écoute également un pipe nommé, exposer ce pipe dans le conteneur Discourse et ajouter mon dossier personnalisé /xyz à la configuration nginx de Discourse afin de le faire proxy_pass vers le pipe nouvellement créé. (Après avoir résolu les détails, par exemple, le nginx hôte doit démarrer en premier, sinon docker-compose n’exposera pas correctement le pipe nommé)

Toute aide est néanmoins la bienvenue :wink:

Cela est dû au fait que le routeur Ember.JS connaît la liste complète des chemins pris en charge par l’application Discourse, et que la page 404 est rendue côté client car il sait que le serveur n’a pas de contenu à cet endroit.

Placez vos fichiers sur un autre sous-domaine.