When doing a search on our discourse site, if I do a regular GET request to /search?q=my search it works fine. But if I use the search box and it submits the search request via an XHR GET request I get a 406 status return.
After some further testing with Postman I found that just adding an X-Requested-With: XMLHttpRequest header to the request breaks it. Remove that one header and it works fine. The server is behind Azure Front Door and bypassing it and hitting the server direct does not have this issue. Is nginx or search doing something special based on that header? Could being behind a reverse proxy interfere? Any idea how to fix?
You reverse proxy should never drop any headers our client app sets. It can result in some obvious bugs, but also in some silent ones you will never find out until too late.
No, because you’re not behind front door. The problem is caused by it going through the proxy, I just don’t know why given other xhr requests are fine. Which suggests something about requests sent to search are handled differently by discourse than other xhr requests.
I’m not using the WAF functionality. I’ll see if I can determine anything further in terms of if it’s otherwise somehow dropping headers or something. Just seems odd that it only affects search requests.
Other WAF product I was debugging last month was also breaking canned replies and draft saving. When it break more infrequently used features it can take a while to find all incompatibilities.
I did some further testing and it does appear FD is incorrectly passing at least this http header. I’ve submitted a request with them to fix. I’m still not sure why search cares about this header, but I guess better to get the FD bug fixed.
We generally advise people to opt out of complex configurations unless they (for some reason) have written in stone requirements that demand them. And in those rare cases, we hope they also allocated the budget to pay experts to help manage that required complexity, too…