On Jan 6, 2011, at 4:56 PM, Alice Bevan–McGregor wrote: > On 2011-01-06 13:06:36 -0800, James Y Knight said: > >> On Jan 6, 2011, at 3:52 PM, Alice Bevan–McGregor wrote: >>> :: Making optional (and thus rarely-implemented) features non-optional. >>> E.g. server support for HTTP/1.1 with clarifications for interfacing >>> applications to 1.1 servers. Thus pipelining, chunked encoding, et. al. as >>> per the HTTP 1.1 RFC. >> Requirements on the HTTP compliance of the server don't really have any >> place in the WSGI spec. You should be able to be WSGI compliant even if you >> don't use the HTTP transport at all (e.g. maybe you just send around >> requests via SCGI). >> The original spec got this right: chunking etc are something which is not >> relevant to the wsgi application code -- it is up to the server to implement >> the HTTP transport according to the HTTP spec, if it's purporting to be an >> HTTP server. > > Chunking is actually quite relevant to the specification, as WSGI and PEP 444 > / WSGI 2 (damn, that's getting tedious to keep dual-typing ;) allow for > chunked bodies regardless of higher-level support for chunking. The body > iterator. Previously you /had/ to define a length, with chunked encoding at > the server level, you don't.
No you don't -- HTTP 1.0 allows indeterminate-length output. The server simply must close the connection to indicate the end of the response if either the client version HTTP/1.0, or the server doesn't implement HTTP/1.1. James _______________________________________________ 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
