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.
I agree, however, that not all gateways will be able to implement the
relevant HTTP/1.1 features. FastCGI does, SCGI after a quick Google
search, seems to support it as well. I should re-word it as:
"For those servers capable of HTTP/1.1 features the implementation of
such features is required."
+1
- 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
