我不确定这里发生了什么事。 我做了一个小东西的东西，然后回来build立HTTP请求，看起来像这样：
POST /update.py HTTP/1.1 Host: iot.example.com Connection: close Content-Type: application/x-www-form-urlencoded Content-Length: [...] iv=[...]&msg=base64(encrypted_msg) 还有一个相应的服务器端python脚本，它从POST数据中提取信息。 我最近将防火墙的反向代理从squid更改为HAProxy，并且突然间Apache正在返回HTTP 400状态，在IOT设备甚至有机会发送POST数据之前，最迟都会看到。 以下是这些交互之一的wireshark TCPstream：
POST /update.py HTTP/1.1 Host: iot.example.com Connection: close Content-Type: application/x-www-form-urlencoded Content-Length: 100 X-Forwarded-Proto: http X-Forwarded-For: xx.xx.xx.xx HTTP/1.1 400 Bad Request Date: Sat, 17 Jun 2017 22:29:45 GMT Server: Apache/2.4.25 (FreeBSD) mod_wsgi/4.5.15 Python/2.7 Content-Length: 226 Connection: close Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>400 Bad Request</title> </head><body> <h1>Bad Request</h1> <p>Your browser sent a request that this server could not understand.<br /> </p> </body></html> iv=En98cormFMA7NO5e-4qh2Q==&msg=ek_JDRJPqPUvNlztUVH6FTtfVVdHgODWMimBcZklos2XntlMOM1RweBjsp5z-zY=
HTTP/1.1 400 Bad Request和</html>之间的所有内容都是服务器回复，其他所有内容都是服务器正在接收的内容。 X-Forwarded *标头由HAProxy设置。 据我所知，Squid没有使用这些 这里真正奇怪的事情是，即使在获取POST数据之前，Apache也在响应。 服务器对GET请求做出了很好的响应，而且我在同一个防火墙后面运行了一些其他的Apache服务器。 我能想到的唯一真正的区别是，这些HTTP请求对于他们来自的微控制器来说是非常难以编码的，也许他们不太适合从头开始。 任何build议将非常感激。 提前致谢！
事实certificate，问题是我的HTTP请求中的行结束。 我正在发送LF和CRLF的混合物。 RFC2616要求HTTP / 1.1只使用CRLF，但是也要规定服务器应该实现“宽容规定” 。 但是，Apache> = 2.4.25默认为HttpProtocolOptions Strict ，它将HTTP/1.1 400状态返回到所有格式错误的标头。
自12月份以来，FreeBSD已经打包了Apache 2.4.25，但是我认为Squid为我调整了标题，因为它没有中断。 我猜HAProxy是更加宽松的票价，所以从Squid到HAProxy的变化让服务器暴露了我的旧固件。
正确的解决办法是用补丁固件重新刷新微控制器，但这是一个麻烦。 一个快速和肮脏的解决方法是告诉Apache放松。 添加HttpProtocolOptions Unsafe对httpd.conf HttpProtocolOptions Unsafe是一个快速“修复”，至less可以让数据logging备份和运行。