Re: wininet: correct the case where Content-Length is set as well as Transer-Encoding = chunked
On Thursday 17 April 2008 20:05:41 Aric Stewart wrote:
+ /* Correct the case where both a Content-Length and Transfer-encoding = chuncked are set */ + + dwBufferSize = sizeof(encoding); + if (HTTP_HttpQueryInfoW(lpwhr, HTTP_QUERY_TRANSFER_ENCODING, encoding, &dwBufferSize, NULL) && + !strcmpiW(encoding, szChunked)) + { + lpwhr->dwContentLength = -1; + }
I think the right thing to do is to strip the Transfer-Encoding header from the request because we don't support chunked transfers in the sending direction. Would that work for you? -Hans
This patch is for the receiving direction, unless I misread the code. The issue is that after a sent request the response is coming back with both Transfer-Encoding=chunked and a Content-Length. -aric Hans Leidekker wrote:
On Thursday 17 April 2008 20:05:41 Aric Stewart wrote:
+ /* Correct the case where both a Content-Length and Transfer-encoding = chuncked are set */ + + dwBufferSize = sizeof(encoding); + if (HTTP_HttpQueryInfoW(lpwhr, HTTP_QUERY_TRANSFER_ENCODING, encoding, &dwBufferSize, NULL) && + !strcmpiW(encoding, szChunked)) + { + lpwhr->dwContentLength = -1; + }
I think the right thing to do is to strip the Transfer-Encoding header from the request because we don't support chunked transfers in the sending direction. Would that work for you?
-Hans
On Thursday 17 April 2008 21:28:57 Aric Stewart wrote:
This patch is for the receiving direction, unless I misread the code.
Well, we're in a loop here, possibly sending and receiving multiple times because of redirects.
The issue is that after a sent request the response is coming back with both Transfer-Encoding=chunked and a Content-Length.
Which webserver is that? RFC2616, section 4.4 states that "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." So it looks like your patch does the right thing when we receive a non-compliant response. I think we have a problem in the sending direction too but we can address that later. -Hans
Here is the download where i see the behavior is where I see the behavior. http://site.ebrary.com/lib/stanford/support/plugins/ebraryReader.exe thanks, -aric Hans Leidekker wrote:
On Thursday 17 April 2008 21:28:57 Aric Stewart wrote:
This patch is for the receiving direction, unless I misread the code.
Well, we're in a loop here, possibly sending and receiving multiple times because of redirects.
The issue is that after a sent request the response is coming back with both Transfer-Encoding=chunked and a Content-Length.
Which webserver is that?
RFC2616, section 4.4 states that "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."
So it looks like your patch does the right thing when we receive a non-compliant response. I think we have a problem in the sending direction too but we can address that later.
-Hans
participants (2)
-
Aric Stewart -
Hans Leidekker