Wenn Sie auf unserer Discourse-Seite eine Suche durchführen, funktioniert eine reguläre GET-Anfrage an /search?q=meine Suche einwandfrei. Verwenden Sie jedoch das Suchfeld und sendet die Suchanfrage über eine XHR-GET-Anfrage, erhalten Sie einen 406-Statuscode.
Nach weiteren Tests mit Postman stellte ich fest, dass das Hinzufügen des Headers X-Requested-With: XMLHttpRequest die Anfrage bereits unterbricht. Entfernt man diesen einen Header, funktioniert es wieder einwandfrei. Der Server befindet sich hinter Azure Front Door, und das Umgehen von Front Door sowie der direkte Zugriff auf den Server lösen dieses Problem nicht. Führt Nginx oder die Suche basierend auf diesem Header etwas Besonderes aus? Könnte der Einsatz eines Reverse-Proxy stören? Haben Sie eine Idee, wie man das Problem beheben kann?
Ihr Reverse-Proxy sollte niemals Header löschen, die von unserer Client-App gesetzt werden. Dies kann zu offensichtlichen Fehlern führen, aber auch zu stillen Fehlern, die Sie erst zu spät entdecken werden.
Ich gehe davon aus, dass der Header nicht entfernt wird, da andere XHR-Anfragen problemlos funktionieren. Es scheint, als wäre diese hier irgendwie anders als die anderen in Discourse.
Nein, weil du dich nicht hinter einer Tür befindest. Das Problem wird durch den Proxy verursacht, aber ich weiß nicht genau warum, da andere XHR-Anfragen problemlos funktionieren. Das deutet darauf hin, dass Anfragen an die Suche von Discourse anders behandelt werden als andere XHR-Anfragen.
Meta läuft hinter einem AWS ALB Reverse-Proxy und zeigt dieses Problem nicht.
Try läuft hinter einem HAProxy Reverse-Proxy und zeigt dieses Problem nicht.
Die meisten selbst gehosteten Instanzen verfügen nur über den internen nginx Reverse-Proxy und zeigen ebenfalls dieses Problem nicht.
Das lässt mich auf Azure Front Door als Ursache schließen. Dies wird nicht das erste Mal sein, dass ein Azure-Produkt sich seltsam und fehlerhaft verhält.
Wir haben zudem Erfahrungen damit gemacht, dass andere WAF-Produkte Discourse beeinträchtigen, weshalb sie nicht unterstützt werden.
Ich verwende die WAF-Funktionalität nicht. Ich werde prüfen, ob ich weitere Erkenntnisse darüber gewinnen kann, ob sie anderweitig auf irgendeine Weise Header verwirft oder ähnliches. Es wirkt nur seltsam, dass dies nur Suchanfragen betrifft.
Ein anderes WAF-Produkt, das ich letzten Monat debuggt habe, hat ebenfalls die vorgefertigten Antworten und das Speichern von Entwürfen beeinträchtigt. Wenn es weniger häufig genutzte Funktionen betrifft, kann es eine Weile dauern, alle Inkompatibilitäten zu finden.
Ich habe weitere Tests durchgeführt und es scheint, als würde FD zumindest diesen HTTP-Header falsch weitergeben. Ich habe eine Anfrage an sie gestellt, um dies zu beheben. Ich bin immer noch nicht sicher, warum die Suche diesen Header beachtet, aber es ist wohl besser, den FD-Fehler zu beheben.
Wir raten den meisten Nutzern grundsätzlich davon ab, komplexe Konfigurationen zu wählen, es sei denn, sie haben (aus irgendeinem Grund) in Stein gemeißelte Anforderungen, die dies erfordern. Und in diesen seltenen Fällen hoffen wir, dass sie auch das Budget bereitgestellt haben, um Experten für die Verwaltung dieser erforderlichen Komplexität einzustellen.