On 2011-01-06 14:01:09 -0800, James Y Knight said:
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.
Ah, you are correct. There was something, somewhere I was reading
related to WSGI about requiring content-length... but no matter.
Interestingly enough, HTTP/1.0 also supports pipelining (though
obviously not if content-length is missing) via the `Connection:
keep-alive` header. HTTP/1.1 mandates keep-alive by default (which is
a good thing, IMHO) and offers a work-around for missing content-length
to preserve the connection: chunked encoding. Add to that 100-Continue
(allowing delayed /transfer/ of the request body until the first
wsgi.input.read() operation) and allows proper, full URLs to be
requested, amongst other goodies.
Arguing against mandated HTTP/1.1 support (where possible) seems...
silly to me. HTTP/1.1 has been around for a long time (adopted by the
major browsers in 1996), is well understood, is /trivial/ to implement
(I managed it as part of my 172 Python opcode HTTP server
implementation), and Just Makes Sense.
If there can be a good technical reason why the adapted language ("if
possible, it's required") can not be used, I'll definitely re-consider
this point. Considering that detection is easy (SERVER_PROTOCOL ==
"1.0"), adaption by the application to either case is easy (detect and
if not present consume the body_iter and determine length) and it's a
15 year old standard: welcome to the 20'th century. ;)
- Alice.
_______________________________________________
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
