<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7651.59">
<TITLE>RE: [Web-SIG] Chunked Tranfer encoding on request content.</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=2>Graham Dumpleton wrote:<BR>
&gt; In CherryPy, when it sees that the Transfer-Encoding<BR>
&gt; is set to 'chunked' while parsing the HTTP headers,<BR>
&gt; it will at that point, even before it has called<BR>
&gt; start_response for the WSGI application, read in all<BR>
&gt; content from the body of the request.<BR>
&gt;<BR>
&gt; CherryPy reads in the content like this for two reasons.<BR>
&gt; The first is so that it can then determine the overall<BR>
&gt; length of the content that was available and set the<BR>
&gt; CONTENT_LENGTH value in the WSGI environ.<BR>
<BR>
Right; IIRC the rfile just hangs if you try to read<BR>
past Content-Length. Perhaps that can be fixed inside<BR>
socket.makefile somewhere?<BR>
<BR>
&gt; The second reason is so that it can read in any<BR>
&gt; additional HTTP header fields that may occur in<BR>
&gt; the trailer after the last data chunk and also<BR>
&gt; incorporate them into the WSGI environ.<BR>
<BR>
Yeah; I didn't see any other way to get Trailers into<BR>
the environ. Perhaps that can be added to WSGI 2.0?<BR>
<BR>
I also just haven't had time to write a dechunker<BR>
which worked on the fly. Patches welcome ;)<BR>
<BR>
&gt; When chunked transfer encoding is not used, such a<BR>
&gt; 100 continue response would in a good WSGI server<BR>
&gt; only be sent when the WSGI application called read()<BR>
&gt; on wsgi.input for the first time.<BR>
<BR>
Sounds reasonable. Again, patches welcome ;)<BR>
<BR>
&gt; Note that I am assuming here that 100 continue is<BR>
&gt; still usable in conjunction with chunked transfer<BR>
&gt; encoding. In CherryPy WSGI server it only actually<BR>
&gt; sends the 100 continue after it attempts to try<BR>
&gt; and read content in the presence of a chunked<BR>
&gt; transfer encoding header. Not sure if this is<BR>
&gt; actually a bug or not.<BR>
<BR>
It looks like a bug. The Expect header should be<BR>
checked before decode_chunked (at least until the<BR>
100 response can be moved inside read()).<BR>
<BR>
Thanks for catching those!<BR>
<BR>
<BR>
Robert Brewer<BR>
System Architect<BR>
Amor Ministries<BR>
fumanchu@amor.org</FONT>
</P>

</BODY>
</HTML>