背景：我编写了一个 Django 应用程序，现在已将其部署到 Elastic Beanstalk (AWS)。在本地开发中，我一直在使用自定义请求标头 SESSION_TOKEN，然后可以使用 r 访问它...
背景：我编写了一个 Django 应用程序，现在已将其部署到 Elastic Beanstalk（AWS）。
在本地开发中，我一直在使用自定义请求标头 SESSION_TOKEN ，然后可以使用 进行访问 request.META.get('HTTP_SESSION_TOKEN') 。在生产中，我看到错误，因为该标头不可访问（也就是说，我的 Django 服务器看到的所有请求中都缺少该标头）。
此外，我的其他标准标头工作正常，只有自定义标头缺失。请注意，我没有设置 HTTP_AUTHORIZATION ，这与 django rest_framework 中缺少授权标头的问题不同 ，是 apache 的错吗？ .
出了什么问题？如何在生产中访问后端的自定义标头？
最有可能的是， SESSION_TOKEN 标头被某些东西剥离了。来自 Django 安全公告 :
当 HTTP 标头被放入 WSGI 环境中时，它们会通过转换为大写、将所有破折号转换为下划线以及在前面添加 HTTP_ 来进行规范化。例如，标头 X-Auth-User 在 WSGI 环境中会变成 HTTP_X_AUTH_USER（因此在 Django 的 request.META 字典中也是如此）。
不幸的是，这意味着 WSGI 环境无法区分包含破折号的标头和包含下划线的标头：X-Auth-User 和 X-Auth_User 都变为 HTTP_X_AUTH_USER。这意味着，如果以安全敏感的方式使用标头（例如，从前端代理传递身份验证信息），即使代理小心地剥离 X-Auth-User 的任何传入值，攻击者也可能能够提供 X-Auth_User 标头（带下划线）并绕过此保护。
最重要的信息是：
为了防止此类攻击，Nginx 和 Apache 2.4+ 都默认从传入请求中删除所有包含下划线的标头。Django 的内置开发服务器现在也这样做。不建议将 Django 的开发服务器用于生产，但匹配常见生产服务器的行为可以减少部署期间行为更改的影响范围。
如果您有任何自定义标题，则应使用连字符。
