windows - 查询 http header 时出现错误 ERROR_WINHTTP_HEADER_NOT_FOUND

Question

在查询 http header (通过 winhttpqueryheaders)时，我收到错误 ERROR_WINHTTP_HEADER_NOT_FOUND，即无法找到所请求的 header 。只有当我请求的数据很大时才会发生这种情况，对于小数据它工作正常。

WinHttpQueryHeaders( hRequest, 
                     WINHTTP_QUERY_CONTENT_LENGTH | WINHTTP_QUERY_FLAG_NUMBER,
                     WINHTTP_HEADER_NAME_BY_INDEX, 
                     &contentLength, 
                     &contentLenBufferSize, 
                     WINHTTP_NO_HEADER_INDEX);

Answer 1

显然 Content-Length header 不存在，否则 WinHttpQueryHeaders() 将不会报告 ERROR_WINHTTP_HEADER_NOT_FOUND。

在许多情况下，Content-Length header 是可选的:

• 如果消息正文使用chunked 传输编码(在 HTTP 1.1 中常用，尤其是对于大数据)，Content-Length header 必须被省略，如果存在则必须被忽略。在您的情况下，这是最有可能的情况。

• 如果消息正文使用的是 multipart/... 媒体类型(自终止)，则可以省略 Content-Length header .

• 如果消息通过关闭套接字终止，则可以省略 Content-Length header 。

因此，并不总是能够在消息开头知道完整的内容长度，有时您只能在到达消息结尾时才能知道长度。您需要查看 Content-Type、Content-Length、Transfer-Encoding 和 Connection header 以根据 RFC 2616 Section 4.4 找出真正发生的事情:

4.4 Message Length   The transfer-length of a message is the length of the message-body as   it appears in the message; that is, after any transfer-codings have   been applied. When a message-body is included with a message, the   transfer-length of that body is determined by one of the following   (in order of precedence):   1.Any response message which "MUST NOT" include a message-body (such     as the 1xx, 204, and 304 responses and any response to a HEAD     request) is always terminated by the first empty line after the     header fields, regardless of the entity-header fields present in     the message.   2.If a Transfer-Encoding header field (section 14.41) is present and     has any value other than "identity", then the transfer-length is     defined by use of the "chunked" transfer-coding (section 3.6),     unless the message is terminated by closing the connection.   3.If a Content-Length header field (section 14.13) is present, its     decimal value in OCTETs represents both the entity-length and the     transfer-length. The Content-Length header field MUST NOT be sent     if these two lengths are different (i.e., if a Transfer-Encoding     header field is present). If a message is received with both a     Transfer-Encoding header field and a Content-Length header field,     the latter MUST be ignored.   4.If the message uses the media type "multipart/byteranges", and the     ransfer-length is not otherwise specified, then this self-     elimiting media type defines the transfer-length. This media type     UST NOT be used unless the sender knows that the recipient can arse     it; the presence in a request of a Range header with ultiple byte-     range specifiers from a 1.1 client implies that the lient can parse     multipart/byteranges responses.       A range header might be forwarded by a 1.0 proxy that does not       understand multipart/byteranges; in this case the server MUST       delimit the message using methods defined in items 1,3 or 5 of       this section.   5.By the server closing the connection. (Closing the connection     cannot be used to indicate the end of a request body, since that     would leave no possibility for the server to send back a response.)   For compatibility with HTTP/1.0 applications, HTTP/1.1 requests   containing a message-body MUST include a valid Content-Length header   field unless the server is known to be HTTP/1.1 compliant. If a   request contains a message-body and a Content-Length is not given,   the server SHOULD respond with 400 (bad request) if it cannot   determine the length of the message, or with 411 (length required) if   it wishes to insist on receiving a valid Content-Length.   All HTTP/1.1 applications that receive entities MUST accept the   "chunked" transfer-coding (section 3.6), thus allowing this mechanism   to be used for messages when the message length cannot be determined   in advance.   Messages MUST NOT include both a Content-Length header field and a   non-identity transfer-coding. If the message does include a non-   identity transfer-coding, the Content-Length MUST be ignored.   When a Content-Length is given in a message where a message-body is   allowed, its field value MUST exactly match the number of OCTETs in   the message-body. HTTP/1.1 user agents MUST notify the user when an   invalid length is received and detected.