Discourse サイトで検索を行う際、/search?q=my search に通常の GET リクエストを送信すれば問題なく動作します。しかし、検索ボックスを使用して XHR GET リクエストで検索を送信すると、406 ステータスが返されます。
その後、Postman でさらにテストを行ったところ、X-Requested-With: XMLHttpRequest ヘッダーをリクエストに追加するだけで動作しなくなることがわかりました。このヘッダーを削除すれば、再び正常に動作します。サーバーは Azure Front Door の背後にあり、Front Door をバイパスしてサーバーに直接アクセスした場合はこの問題が発生しません。nginx または検索機能がこのヘッダーに基づいて何か特別な処理を行っているのでしょうか？リバースプロキシの背後にあることが影響している可能性はありますか？解決策についてご存知でしょうか？
リバースプロキシは、クライアントアプリが設定するすべてのヘッダーを絶対に破棄してはいけません。これにより、明らかなバグだけでなく、手遅れになるまで決して発見できないような静かなバグも発生する可能性があります。
他の XHR リクエストは正常に動作しているため、ヘッダーが削除されていないと推測します。Discourse において、このリクエストだけが何らかの理由で他と異なっているようです。
Meta でも同じエラーを再現できますか？
いいえ、フロントドアの裏にいないからです。問題はプロキシを経由していることが原因ですが、他の XHR リクエストは正常に動作しているため、なぜそうなるのか分かりません。これは、検索へのリクエストが Discourse によって他の XHR リクエストとは異なって処理されている可能性を示唆しています。
Meta は AWS ALB リバースプロキシの背後で動作しており、この問題が発生していません。
Try は HAProxy リバースプロキシの背後で動作しており、この問題が発生していません。
ほとんどのセルフホストインスタンスは内部の nginx リバースプロキシのみを備えており、この問題も発生していません。
このため、Azure Front Door が疑われます。Azure の製品が 奇妙な破損した動作 を示すのは、これが初めてではありません。
また、他の WAF 製品が Discourse を破損させる経験もあるため、それらはサポートされていません。
WAF機能は使用していません。ヘッダーの削除など、他の要因がないか確認してみます。検索リクエストのみが影響を受けるのは、少し不自然に思えます。
先月デバッグしていた別の WAF プロダクトも、定型返信の機能や下書きの保存機能を壊していました。WAF があまり頻繁に使われない機能を壊した場合、すべての非互換性を見つけるのに時間がかかることがあります。
さらにテストを行ったところ、FD が少なくともこの HTTP ヘッダーを誤って渡しているようです。修正を依頼するチケットを提出しました。検索がなぜこのヘッダーを気にするのかは依然として不明ですが、FD のバグを修正したほうが良いと思います。
一般的に、複雑な構成を避けることをお勧めします。どうしても書き換え不可能な要件があり、それが必要になる場合を除きます。そのような稀なケースでは、その必要な複雑さを管理するための専門家への予算も確保されていることを願っています。