Re: wininet: correct the case where Content-Length is set as well as Transer-Encoding = chunked

[Hans Leidekker]

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

wininet: correct the case where Content-Length is set as well as Transer-Encoding = chunked

[Aric Stewart]

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

wininet: correct the case where Content-Length is set as well as Transer-Encoding = chunked

[Hans Leidekker]

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

wininet: correct the case where Content-Length is set as well as Transer-Encoding = chunked

[Aric Stewart]

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