Robert Brewer wrote ..
> Graham Dumpleton wrote:
> > In CherryPy, when it sees that the Transfer-Encoding
> > is set to 'chunked' while parsing the HTTP headers,
> > it will at that point, even before it has called
> > start_response for the WSGI application, read in all
> > content from the body o
On 3/4/07, Graham Dumpleton <[EMAIL PROTECTED]> wrote:
> I am not talking about the response body. I am talking about the body of
> the request. For example, the body of a POST request being sent from
> client to server.
Ah, ok. Anyway I don't see why it would need to read the whole body to
do chu
Graham Dumpleton wrote:
> In CherryPy, when it sees that the Transfer-Encoding
> is set to 'chunked' while parsing the HTTP headers,
> it will at that point, even before it has called
> start_response for the WSGI application, read in all
> content from the body of the request.
>
> CherryPy reads
Sidnei da Silva wrote ..
> I'm not quite aware of the 100 Continue semantics, but I know that
> applications which request Transfer-Encoding: chunked should *not*
> expect a Content-Length response header, nor should the WSGI thingie
> doing the 'chunking' need to know it in advance.
>
> 'chunked'
I'm not quite aware of the 100 Continue semantics, but I know that
applications which request Transfer-Encoding: chunked should *not*
expect a Content-Length response header, nor should the WSGI thingie
doing the 'chunking' need to know it in advance.
'chunked' is actually very simple. Simplifying
The WSGI specification doesn't really say much about chunked transfer encoding
for content sent within the body of a request. The only thing that appears to
apply is the comment:
WSGI servers must handle any supported inbound "hop-by-hop" headers on their
own, such as by decoding any inbound T
