httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: cvs commit: httpd-2.0 CHANGES
Date Sat, 29 Sep 2001 12:48:40 GMT

In a message dated 01-09-29 05:02:10 EDT, justin wrote...

>  Call get_mime_headers again when we receive the zero chunk so that we
>  read the trailer headers correctly.  This requires refactoring
>  get_mime_headers, so I'd rather wait a bit on this.

IMHO you are better off knowing before you even start dechunking
if client send TE: and/or 'trailers' flag.

The classic condition you want to be able to handle is this...

1. Netscape browser sends up some HUGE amount of POST
data ( very common these days with web-apps proliferating )
using 'Transfer-Encoding: chunked'.
2. May or may not have 'trailers' to append.
3. Netscape will also always automatically add the 'out of band'
blank CR/LF following the post data to satisfy legacy UNIX cgi
that uses fgets() so those CGI IO calls won't get 'stuck'. This
'out of band' CR/LF is NOT included in the 'Content-length:' nor
is it included in any Transfer-Encoding 'chunk'. Netscape simply
'tacks it on' to end of whatever is sent to host.

Problem then becomes...

1. Will the EOM ( End of Message ) look like this...

(Last data chunk)
0 CR/LF ( End of data )

2. Or will it be this?...

(Last data chunk)
0 CR/LF ( End of data )
CR/LF ( End of trailers? Out of band CR/LF? which? )

3. Or will it be this?...

(Last data chunk)
0 CR/LF ( End of data )
CR/LF ( End of trailers )
CR/LF ( Out of band CR/LF sent by Netscape browsers ).

There is no way to interpret EOM correctly given the mysterious
way Transfer-Encoding is allowed to finish + the weird 'out of band'
CR/LF sutff coming from Netscape unless you know for sure 
going into the dechunking if the client has sent TE: and/or the
'trailers' value.

Kevin Kiley

View raw message