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 in the content like this for two reasons. > The first is so that it can then determine the overall > length of the content that was available and set the > CONTENT_LENGTH value in the WSGI environ.
Right; IIRC the rfile just hangs if you try to read past Content-Length. Perhaps that can be fixed inside socket.makefile somewhere? > The second reason is so that it can read in any > additional HTTP header fields that may occur in > the trailer after the last data chunk and also > incorporate them into the WSGI environ. Yeah; I didn't see any other way to get Trailers into the environ. Perhaps that can be added to WSGI 2.0? I also just haven't had time to write a dechunker which worked on the fly. Patches welcome ;) > When chunked transfer encoding is not used, such a > 100 continue response would in a good WSGI server > only be sent when the WSGI application called read() > on wsgi.input for the first time. Sounds reasonable. Again, patches welcome ;) > Note that I am assuming here that 100 continue is > still usable in conjunction with chunked transfer > encoding. In CherryPy WSGI server it only actually > sends the 100 continue after it attempts to try > and read content in the presence of a chunked > transfer encoding header. Not sure if this is > actually a bug or not. It looks like a bug. The Expect header should be checked before decode_chunked (at least until the 100 response can be moved inside read()). Thanks for catching those! Robert Brewer System Architect Amor Ministries [EMAIL PROTECTED]
_______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com