考虑一个类似的HTTP请求：
POST / HTTP/1.1
Host: 127.0.0.1
Connection: keep-alive
Accept: */*
User-Agent: NonExistent Client
Content-Length: 4
foo=bar字符串
正如你所看到的，请求是无效的，例如。有效载荷长度是7个字节，但CL头只包含4个字节。
Nginx对此请求给出了两个响应：
HTTP/1.1 404 Not Found
Date: Fri, 03 Mar 2023 20:55:02 GMT
Content-Type: text/html
Content-Length: 146
Connection: keep-alive
Vary: Accept-Encoding
X-XSS-Protection: 0
X-Content-Type-Options: nosniff
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>
HTTP/1.1 400 Bad Request
Date: Fri, 03 Mar 2023 20:55:02 GMT
Content-Type: text/html
Content-Length: 150
Connection: close
X-XSS-Protection: 0
X-Content-Type-Options: nosniff
<html>
<head><title>400 Bad Request</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx</center>
</body>
</html>型
第一个响应包含“正常”404，这是我所期望的。
第二个响应是因为服务器继续处理请求-这是一个完全错误的请求，它给出了400。
服务器写入日志条目：
2023/03/03 20:55:02 [info] 27273#27273: *8 client sent invalid method while reading client pipelined request line, client: 192.168.72.2, server: _, request: "bar"型
这就是为什么我认为它会继续处理分块的请求。
有没有办法避免这种行为，即抑制第二种React？
1条答案
按热度按时间pzfprimi1#
防止这种情况的一种方法是在nginx配置中设置
keepalive_requests 1;。这将导致它在处理第一个请求后总是挂起，但这可能会对行为良好的客户端的性能产生负面影响。
从理论上讲，似乎可以只为特定的用户代理禁用
keep-alive，但this表明nginx不支持这一点。显然，您也不能将keepalive_requests放在if ($http_user_agent ~ NonExistent) {}块中。除此之外，似乎你最好的办法是修复坏掉的客户端。如果你不能让它发送正确的
Content-Length，也许你可以配置它不请求keep-alive？