Lorsque vous effectuez une recherche sur notre site Discourse, une requête GET classique vers /search?q=ma recherche fonctionne parfaitement. Cependant, si vous utilisez la barre de recherche qui soumet la requête via une requête GET XHR, vous recevez un statut 406.
Après d’autres tests avec Postman, j’ai constaté que l’ajout simple de l’en-tête X-Requested-With: XMLHttpRequest à la requête la fait échouer. Si vous supprimez cet en-tête, tout fonctionne correctement. Le serveur est derrière Azure Front Door, et en le contournant pour accéder directement au serveur, ce problème n’apparaît pas. Est-ce que nginx ou le module de recherche fait quelque chose de spécial basé sur cet en-tête ? Le fait d’être derrière un proxy inverse peut-il interférer ? Avez-vous une idée de la façon de résoudre ce problème ?
Votre reverse proxy ne doit jamais supprimer les en-têtes définis par notre application cliente. Cela peut entraîner des bugs évidents, mais aussi des bugs silencieux que vous ne découvrirez qu’une fois trop tard.
Je suppose que ce n’est pas l’en-tête qui est supprimé, étant donné que d’autres requêtes XHR fonctionnent correctement. Il semble que celle-ci soit en quelque sorte différente des autres dans Discourse.
Non, car vous n’êtes pas derrière la porte d’entrée. Le problème est causé par le passage par le proxy ; je ne sais tout simplement pas pourquoi, étant donné que d’autres requêtes XHR fonctionnent correctement. Cela suggère que les requêtes envoyées à la recherche sont traitées différemment par Discourse par rapport aux autres requêtes XHR.
Je n’utilise pas la fonctionnalité WAF. Je vais voir si je peux déterminer d’autres éléments, par exemple si elle supprime des en-têtes ou autre de toute autre manière. C’est simplement étrange que cela n’affecte que les requêtes de recherche.
Un autre produit WAF que j’ai débugué le mois dernier provoquait également la rupture des réponses préenregistrées et de la sauvegarde des brouillons. Lorsqu’il affecte des fonctionnalités moins fréquemment utilisées, il peut falloir du temps pour identifier toutes les incompatibilités.
J’ai effectué d’autres tests et il semble que FD transmette incorrectement au moins cet en-tête HTTP. J’ai soumis une demande auprès d’eux pour corriger le problème. Je ne suis toujours pas certain de la raison pour laquelle la recherche se soucie de cet en-tête, mais il vaut mieux corriger ce bug de FD.
Nous conseillons généralement aux personnes de ne pas opter pour des configurations complexes, sauf si elles ont, pour une raison quelconque, des exigences figées qui les imposent. Et dans ces rares cas, nous espérons qu’elles ont également prévu un budget pour payer des experts afin de gérer cette complexité requise.