# Xhr search requests return 406
**URL:** https://meta.discourse.org/t/xhr-search-requests-return-406/147428
**Category:** Self-hosting
**Created:** [April 9, 2020, 4:07pm UTC](https://meta.discourse.org/t/xhr-search-requests-return-406/147428 "2020-04-09T16:07:18Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@NotAnonymous](https://meta.discourse.org/u/NotAnonymous)
#### Post date: [April 9, 2020, 4:07pm UTC](https://meta.discourse.org/t/xhr-search-requests-return-406/147428/1 "2020-04-09T16:07:18Z")
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?
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [April 9, 2020, 4:15pm UTC](https://meta.discourse.org/t/xhr-search-requests-return-406/147428/2 "2020-04-09T16:15:42Z")
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.
---
### Author:  [@NotAnonymous](https://meta.discourse.org/u/NotAnonymous)
#### Post date: [April 9, 2020, 4:21pm UTC](https://meta.discourse.org/t/xhr-search-requests-return-406/147428/3 "2020-04-09T16:21:00Z")
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.
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [April 9, 2020, 4:21pm UTC](https://meta.discourse.org/t/xhr-search-requests-return-406/147428/4 "2020-04-09T16:21:45Z")
Can you reproduce this same error here on Meta?
---
### Author:  [@NotAnonymous](https://meta.discourse.org/u/NotAnonymous)
#### Post date: [April 9, 2020, 4:26pm UTC](https://meta.discourse.org/t/xhr-search-requests-return-406/147428/5 "2020-04-09T16:26:08Z")
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.
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [April 9, 2020, 4:37pm UTC](https://meta.discourse.org/t/xhr-search-requests-return-406/147428/6 "2020-04-09T16:37:42Z")
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](https://meta.discourse.org/t/invalid-input-for-update-ip-address/77085/13).
We also have experience with other WAF products breaking Discourse, so they aren’t supported.
> [@Discourse + Web Application Firewall (WAF) mod\_security](https://meta.discourse.org/t/discourse-web-application-firewall-waf-mod-security/133612/3):
>
> This is a bad idea and it is not recommended. The benefit of this type of thing for a JavaScript app is extremely limited and it adds significant complexity to your hosting setup.
> [@Discourse + Web Application Firewall (WAF) mod\_security](https://meta.discourse.org/t/discourse-web-application-firewall-waf-mod-security/133612/6):
>
> I think the desire for some magic device that auto mitigates issues is somewhat misguided in the Discourse setup. We have a bounty program, we patch issues in Discourse within hours of when they are reported. Sites run tests-passed by default which in today’s case contains commits from today. Sure if you are running software that was exploited years ago and you have no freedom to upgrade cause … reasons… a WAF makes sense cause it could save you. But in the case of Discourse I think it is at be…
---
### Author:  [@NotAnonymous](https://meta.discourse.org/u/NotAnonymous)
#### Post date: [April 9, 2020, 4:40pm UTC](https://meta.discourse.org/t/xhr-search-requests-return-406/147428/7 "2020-04-09T16:40:57Z")
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.
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [April 9, 2020, 4:43pm UTC](https://meta.discourse.org/t/xhr-search-requests-return-406/147428/8 "2020-04-09T16:43:12Z")
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.
---
### Author:  [@NotAnonymous](https://meta.discourse.org/u/NotAnonymous)
#### Post date: [April 9, 2020, 5:26pm UTC](https://meta.discourse.org/t/xhr-search-requests-return-406/147428/9 "2020-04-09T17:26:01Z")
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.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [April 9, 2020, 8:03pm UTC](https://meta.discourse.org/t/xhr-search-requests-return-406/147428/10 "2020-04-09T20:03:20Z")
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..