☰

确定格式错误（错误）的 http 请求的结束

tag-icon • tag-icon http parsing bad-request
确定格式错误（错误）的 http 请求的结束

我正在实现一个 HTTP 服务器，想知道是否存在一种定义好的方法，来判断服务器何时会将一个错误的请求终止于

  1. 返回相应的 400 状态，并且
  2. 接受以下数据作为新请求并开始新一次解析尝试。

我想到的唯一想法是非常模糊的：搜索收到的下一个请求行式数据并从那里开始新的解析尝试。然而，正如所说，这是一种非常模糊的方法，因为错误请求的数据当然可能包含所述“请求行式”数据，而实际上并不打算将其作为单独的新请求。

当考虑客户端对格式错误的响应进行响应解析时也会出现同样的问题，因此考虑到这种情况将不胜感激。

答案1

标题以 结尾\r\n\r\n。您只需解析需要读取的每个条目并将它们拆分为参数、strtok ? 或 strstr，或者手动拆分。

如果您更多地谈论 GET 行；

HTTP 协议不会对
URI 的长度设置任何先验限制。服务器必须能够处理它们
所服务的任何资源的 URI，并且如果它们提供可以生成此类 URI 的基于 GET 的表单，则应该能够处理无限长的 URI
。如果 URI 的长度超出服务器可以处理的范围，则服务器
应该返回 414（请求 URI 太长）状态
（请参阅第 10.4.15 节）。

  Note: Servers ought to be cautious about depending on URI lengths
  above 255 bytes, because some older client or proxy
  implementations might not properly support these lengths.

请参阅RFC 2616使您的Web服务器按照标准重新作出反应。

注意，如果您想支持 HTTP1.0+，请确保您也准备好使用 chunk 属性，否则您的服务器将采用 HTTP0.9 标准。

答案2

经过一番考虑，很明显，没有一种通用的方法来确定格式错误的消息的结尾，因为消息总是包含一些自描述信息（例如Content-Length标头字段），使接收者能够真正理解消息。例如，如果响应如下所示：

HTTP/1.1 200 OK
Content-Length: [ consider correct content length here ]
Content-Type: text/html
<html>
    <head>
        <title>Title</title>
    </head>
    <body>
HTTP OK status messages look like this:
HTTP/1.1 200 OK
    </body>
</html>

客户端解析器很可能一开始就失败，因为它需要另一个不允许的<标头字段名称（由于 -header 后有一个换行符） 。此外，它（可能）不应该在以下数据中“搜索”另一个有效的 HTTP 响应，因为它可能会收到像给定的消息正文，其中显示，但这并不是一个新的响应。Content-Type<HTTP/1.1 200 OK

因此，对格式错误的 http 消息的最佳反应似乎是关闭连接，因为任何其他尝试解释收到的以下数据的行为都不可避免地会产生歧义。

然而据我所知，RFC 并未对此进行任何规定。可能是因为 RFC 更多的是定义标准，而不是处理非标准行为。

相关内容