Xhr search requests return 406

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.

I’m assuming it’s not dropping the header, given other XHR requests work fine. Seems like this one is somehow different than others in Discourse.

Can you reproduce this same error here on Meta?

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.

Meta runs behind an AWS ALB reverse proxy and doesn’t exhibit this problem.

Try runs behind an HAProxy reverse proxy and doesn’t exhibit this problem.

Most self hosted instances only have the internal nginx reverse proxy and also doesn’t exhibit this problem.

That makes me suspect the Azure Front Door. This won’t be the first time an Azure product has weird broken behavior.

We also have experience with other WAF products breaking Discourse, so they aren’t supported.

1 Like

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.

1 Like

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…