당사 Discourse 사이트에서 검색을 수행할 때, /search?q=my search에 대한 일반 GET 요청을 보내면 정상적으로 동작합니다. 하지만 검색 상자를 사용하여 XHR GET 요청으로 검색을 제출하면 406 상태 코드가 반환됩니다.
Postman으로 추가 테스트를 해본 결과, 요청에 X-Requested-With: XMLHttpRequest 헤더만 추가해도 문제가 발생한다는 것을 확인했습니다. 해당 헤더를 제거하면 정상적으로 동작합니다. 서버는 Azure Front Door 뒤에 위치해 있으며, 이를 우회하여 서버에 직접 요청을 보내면 이러한 문제가 발생하지 않습니다. nginx 또는 검색 기능이 해당 헤더에 따라 특별한 처리를 수행하고 있는 것일까요? 리버스 프록시 뒤에 위치해 있기 때문에 간섭이 발생할 수 있을까요? 수정 방법에 대한 아이디어가 있을까요?
리버스 프록시는 클라이언트 앱이 설정하는 헤더를 절대 제거해서는 안 됩니다. 이를 통해 눈에 띄는 버그가 발생할 수 있을 뿐만 아니라, 너무 늦게야 발견할 수 있는 은밀한 버그의 원인이 될 수도 있습니다.
다른 XHR 요청은 정상적으로 작동하므로 헤더가 누락되는 문제는 아닌 것 같습니다. Discourse에서 이 요청만 다른 요청들과 어떻게 다른지 궁금합니다.
메타에서 동일한 오류를 재현할 수 있을까요?
아니요, 프론트 도어 뒤에 있지 않기 때문이 아닙니다. 문제는 프록시를 통해 요청이 전송되기 때문인데, 다른 xhr 요청은 문제가 없으므로 왜 그런지는 정확히 알 수 없습니다. 이는 검색으로 전송되는 요청이 다른 xhr 요청과 달리 Discourse에서 다르게 처리되고 있음을 시사합니다.
Meta는 AWS ALB 리버스 프록시 뒤에 있으며 이 문제가 발생하지 않습니다.
Try는 HAProxy 리버스 프록시 뒤에 있으며 이 문제가 발생하지 않습니다.
대부분의 셀프 호스팅 인스턴스는 내부 nginx 리버스 프록시만 사용하고 있으며, 이 문제도 발생하지 않습니다.
이로 인해 Azure Front Door에 문제가 있을 것으로 의심됩니다. Azure 제품에서 이상한 동작 오류가 발생한 것은 이번이 처음이 아닙니다.
또한 다른 WAF 제품으로 인해 Discourse가 깨지는 경험도 있어, 이러한 제품은 지원되지 않습니다.
WAF 기능을 사용하지 않고 있습니다. 헤더를 다른 방식으로 드롭하는지 등을 확인해 볼 수 있을지 알아보겠습니다. 검색 요청에만 영향을 미친다는 점이 좀 이상하게 느껴집니다.
지난달 디버깅을 진행했던 다른 WAF 제품도 미리 작성된 답변과 초안 저장을 깨뜨리는 문제가 있었습니다. 덜 자주 사용되는 기능이 손상되는 경우, 모든 호환성 문제를 찾아내는 데 시간이 좀 걸릴 수 있습니다.
추가 테스트를 해본 결과, FD가 이 HTTP 헤더를 적절히 전달하지 않는 것으로 보입니다. 해당 문제를 수정해 달라고 요청을 제출했습니다. 검색 기능이 왜 이 헤더에 신경을 쓰는지는 여전히 명확하지 않지만, 어쨌든 FD의 버그를 먼저 수정하는 것이 더 나은 것 같습니다.
일반적으로 우리는 복잡한 구성을 선택하지 않는 것을 권장합니다. 다만, 이를 요구하는 석에 새겨진 요구 사항이 있는 경우(어떤 이유에서든)는 예외입니다. 그리고 그런 드문 경우에도, 해당 복잡성을 관리할 전문가에게 비용을 지불할 예산을 확보했기를 바랍니다.