JQuery和其他框架添加以下标题：
X-Requested-With：XMLHttpRequest
为什么需要这个？为什么服务器希望以不同于正常请求的方式处理AJAX请求？
更新：我刚刚找到了一个使用此标题的真实示例：https://core.spreedly.com/manual/payment-methods/adding-with-js。如果在没有AJAX的情况下请求支付处理器，它会在完成后重定向回原始网站。当使用AJAX请求时，不会进行重定向。
答案 0 :(得分：220)
一个很好的理由是安全性 - 这可以防止CSRF攻击，因为未经服务器同意CORS，此标头无法添加到AJAX请求跨域。
跨域只允许以下标题：
- 接受
- 接受语言
- 内容的语言
- 最后-事件ID
- 内容类型
任何其他人都会导致飞行前＃34;请求在CORS支持的浏览器中发布。
如果没有CORS，则无法将X-Requested-With添加到跨域XHR请求中。
如果服务器正在检查此标头是否存在，则它知道该请求未从攻击者的域尝试使用JavaScript代表该用户发出请求。这还会检查请求是否未从常规HTML表单发布，如果不使用令牌，则更难以验证它是否为跨域。 （但是，checking the Origin header可以是支持的浏览器中的一个选项although you will leave old browsers vulnerable。）
您可能希望combine this with a token，因为Flash在OSX can set this header if there's a redirect step上的Safari上运行。它显示为it also worked on Chrome，但现在已经过修复。 More details here包括受影响的不同版本。
OWASP Recommend combining this with an Origin and Referer check：
这种防御技术在4.3节中有具体讨论 跨站请求伪造的强大防御。然而，绕道而行 使用Flash的这种防御早在2008年就被记录下来了 最近由Mathias Karlsson于2015年开始在Vimeo中利用CSRF漏洞。 但是，我们认为Flash攻击无法欺骗Origin或 Referer标题所以通过检查它们我们相信这一点 检查组合应防止Flash绕过CSRF攻击。 （注意： 如果有人可以确认或反驳这一信念，请告诉我们 可以更新这篇文章）
然而，由于已经讨论过的原因，检查Origin可能很棘手。
在CORS, CSRF and X-Requested-With here上撰写更深入的博文。
答案 1 :(得分：21)
请务必阅读SilverlightFox的答案。它突出了一个更重要的原因。
原因主要在于，如果您知道请求的来源，您可能需要对其进行一些自定义。
例如，假设您有一个拥有许多食谱的网站。并且您使用自定义jQuery框架根据他们单击的链接将配方滑动到容器中。
链接可能是www.example.com/recipe/apple_pie
现在通常会返回整页，页眉，页脚，食谱内容和广告。但如果有人在浏览您的网站，其中一些部分已经加载。因此，您可以使用AJAX来获取用户选择的配方，但是为了节省时间和带宽，请不要加载页眉/页脚/广告。
现在，您可以为www.example.com/recipe_only/apple_pie这样的数据编写辅助端点，但这种端点更难以维护并与其他人共享。
但是更容易发现它是一个发出请求的ajax请求，然后只返回部分数据。这样，用户浪费的带宽就会减少，而且网站的响应速度也会提高。
框架只是添加标题，因为有些人可能会发现跟踪哪些请求是ajax而哪些不是ajax很有用。但它完全依赖开发人员来使用这些技术。
它实际上类似于Accept-Language标题。浏览器可以请求网站，请向我显示本网站的俄语版本，而无需在URL中插入/ ru /或类似内容。
答案 2 :(得分：7)
某些框架正在使用此标头来检测xhr请求，例如grails spring security使用此标头来识别xhr请求，并将json响应或html响应作为响应。
大多数Ajax库（从v2.1开始的Prototype，JQuery和Dojo）包含一个X-Requested-With标头，指示请求是由XMLHttpRequest发出的，而不是通过单击常规超链接或表单提交按钮来触发。
来源：http://grails-plugins.github.io/grails-spring-security-core/guide/helperClasses.html