HTTP 结束 header
End of HTTP header
我正在尝试构建一个程序来识别 header 的结尾。现在我知道 http headers 以空行结尾，如 中所述，但是，据我所知，情况并非总是如此。
例如在 multipart 中，您有一个带边界的 content-type，并且在该边界中有一个空的 space，例如
Reading line: POST /hello:hello HTTP/1.1
Reading line: bla: bla
Reading line: Content-Type: multipart/form-data; boundary=--------------------------276559868742390689469124
Reading line: cache-control: no-cache
Reading line: Postman-Token: be8db757-81f4-49db-9187-30d66d0dd3d5
Reading line: User-Agent: PostmanRuntime/7.1.5
Reading line: Accept: */*
Reading line: Host: localhost:8080
Reading line: accept-encoding: gzip, deflate
Reading line: content-length: 498
Reading line: Connection: keep-alive
Reading line:
Reading line: ----------------------------276559868742390689469124
Reading line: Content-Disposition: form-data; name=""; filename="TimeComplexity.txt"
Reading line: Content-Type: text/plain
所以显然寻找一个空 space 似乎并不是每次都有效。不过，我注意到 Content-Type 后跟 space 似乎总是 HTTP header 的结尾，对吗？如果没有，还有哪些其他解决方案？除了提取content-length和提取header之前的内容外，似乎..很慢。还可以提到我正在尝试解析 java 中的消息，但如果您粘贴任何代码，我不介意其他语言的示例，但是，我试图从理论上理解它，我相信我可以管理剩下的
提前致谢！
HTTP headers 可以是任何顺序。每个 header 都以 CRLF 结尾，在最后一个 header 之后有一个 CRLF 创建一个空行。这表示不再有 header。剩下的就是 HTTP 消息 body。请参阅 RFC 2616 了解 HTTP 协议规范。
您的最后一个 HTTP header 是 Connection header。以下 body 数据（大小为 498 字节）是 multipart/form-data 格式的 MIME 数据。 MIME 看起来与 HTTP 类似，因为它也有 headers 和 body 由空行分隔。但是 MIME 也有分隔 MIME 数据不同部分的边界，每个部分都有自己的 headers 和 body。请参阅 RFC 2045 - 2047, 7578 和其他 MIME 相关的 RFC。
我正在尝试构建一个程序来识别 header 的结尾。现在我知道 http headers 以空行结尾，如
例如在 multipart 中，您有一个带边界的 content-type，并且在该边界中有一个空的 space，例如
Reading line: POST /hello:hello HTTP/1.1
Reading line: bla: bla
Reading line: Content-Type: multipart/form-data; boundary=--------------------------276559868742390689469124
Reading line: cache-control: no-cache
Reading line: Postman-Token: be8db757-81f4-49db-9187-30d66d0dd3d5
Reading line: User-Agent: PostmanRuntime/7.1.5
Reading line: Accept: */*
Reading line: Host: localhost:8080
Reading line: accept-encoding: gzip, deflate
Reading line: content-length: 498
Reading line: Connection: keep-alive
Reading line:
Reading line: ----------------------------276559868742390689469124
Reading line: Content-Disposition: form-data; name=""; filename="TimeComplexity.txt"
Reading line: Content-Type: text/plain
所以显然寻找一个空 space 似乎并不是每次都有效。不过，我注意到 Content-Type 后跟 space 似乎总是 HTTP header 的结尾，对吗？如果没有，还有哪些其他解决方案？除了提取content-length和提取header之前的内容外，似乎..很慢。还可以提到我正在尝试解析 java 中的消息，但如果您粘贴任何代码，我不介意其他语言的示例，但是，我试图从理论上理解它，我相信我可以管理剩下的
提前致谢！
HTTP headers 可以是任何顺序。每个 header 都以 CRLF 结尾，在最后一个 header 之后有一个 CRLF 创建一个空行。这表示不再有 header。剩下的就是 HTTP 消息 body。请参阅 RFC 2616 了解 HTTP 协议规范。
您的最后一个 HTTP header 是 Connection header。以下 body 数据（大小为 498 字节）是 multipart/form-data 格式的 MIME 数据。 MIME 看起来与 HTTP 类似，因为它也有 headers 和 body 由空行分隔。但是 MIME 也有分隔 MIME 数据不同部分的边界，每个部分都有自己的 headers 和 body。请参阅 RFC 2045 - 2047, 7578 和其他 MIME 相关的 RFC。