Buffalo 请求最可靠的识别依据是请求头 X-Requested-With: XMLHttpRequest，其他如 Content-Type、JSESSIONID Cookie 等为辅助特征；服务端须严格全等匹配该 header，不可依赖 URL、参数或大小写不敏感写法，且需确保反向代理透传该头。
Buffalo 框架本身不提供“判断是否为 AJAX 请求”的内置 API，服务端需靠标准 HTTP 请求头识别。它不像 Spring MVC 那样有 @RequestBody 或 HttpServletRequest.isXmlHttpRequest() 这类封装，底层仍是基于 Servlet 规范，所以得手动检查 X-Requested-With 头是否为 XMLHttpRequest。
Buffalo 请求的特征请求头有哪些
Buffalo 的 JavaScript 客户端（buffalo.js）在发起远程调用时，会自动带上几个关键请求头：
-
X-Requested-With: XMLHttpRequest—— 所有 Buffalo 请求都带这个，是判断 AJAX 最可靠的依据 -
Content-Type: application/x-www-form-urlencoded或application/json（取决于参数序列化方式） - 若启用了 session，通常还带
JSESSIONIDCookie
注意：Buffalo 不会发送 X-Forwarded-For 或自定义前缀头（如 X-Buffalo-Call），不要依赖不存在的标识。
Java 后端如何安全判断 Buffalo 请求
在 Filter 或 Action 中，用标准 Servlet 方式检查即可，别写错大小写或空格：
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
String xhrHeader = request.getHeader("X-Requested-With");
if ("XMLHttpRequest".equals(xhrHeader)) {
// 是 Buffalo 或其他标准 AJAX 请求
}
常见错误：
- 写成
request.getHeader("x-requested-with")—— 虽然部分容器不区分大小写，但 Servlet 规范未保证，应统一用首字母大写的原始写法 - 用
contains("XML")或startsWith("XML")—— 有被伪造风险，必须严格全等匹配 - 在
doFilter中漏掉chain.doFilter(request, response)导致请求中断
为什么不能靠 URL 路径或参数判断
Buffalo 的 endpoint 路径（如 /bfapp）只是配置项，可任意修改；参数名（如 userService.login）也完全由前端传入，服务端无强制校验机制。曾有人试图通过解析请求体里的 method 字段来判断，但：
- 该字段是业务逻辑层面的 Bean 方法名，不是协议层标识
- 攻击者可直接 POST 相同格式数据绕过判断
- 与真正的 AJAX 判定目的无关（比如你想做 CSRF 防护或返回不同 Content-Type）
真正需要区分请求类型时，只认 X-Requested-With，其他都是干扰项。
Buffalo 的请求本质就是一次标准的 XMLHttpRequest，它的“框架感”只体现在客户端封装和后端 Bean 注册机制上，协议层毫无特殊。最容易被忽略的是：某些反向代理（如 Nginx）默认会剥离 X-Requested-With 头，此时判断必然失效——务必检查代理配置是否透传该 header。
