[Web-SIG] PEP 444 (aka Web3)
Robert Brewer
fumanchu at aminus.org
Thu Sep 16 18:19:35 CEST 2010
Chris McDonough wrote:
> A PEP was submitted and accepted today for a WSGI successor protocol
> named Web3:
>
> http://python.org/dev/peps/pep-0444/
>
> I'd encourage other folks to suggest improvements to that spec or to
> submit a competing spec, so we can get WSGI-on-Python3 settled soon.
Thanks Chris, a few comments:
1. Hooray for all-byte output.
2. Hardly anybody implements RFC 2047, and http-bis is phasing it out.
In addition, since folded and/or 2047-encoded lines are equivalent
to their non-folded-nor-encoded variants, applications have no
business emitting folded or encoded versions of these; that decision
should be left up to the origin server. So keep the text about
control characters, carriage returns and linefeeds, please.
3. +1 on (status, headers, body) in that order. Your own example code
composed them in that order, and then re-arranged them for output!
One of the benefits of a new spec is the opportunity to coerce
rewrites in existing codebases that undo their poor design choices
and make them more readable. By the way, the "Specification Details"
and "Values Returned" sections have this in the (s, h, b) order in
your draft.
4. The web3 spec says, "In case a content length header is absent the
stream must not return anything on read. It must never request more
data than specified from the client." but later it says, "Web3
servers must handle any supported inbound "hop-by-hop" headers on
their own, such as by decoding any inbound Transfer-Encoding,
including chunked encoding if applicable.". I would be sad if web3
did not support streaming uploads via Transfer-Encoding. One way to
implement that would be to make the origin server handle read()
transparently by returning '' on EOF, regardless of whether a
Content-Length or a Transfer-Encoding header was provided.
5. Conversely, streaming output is nice to have and should be
explicitly
supported in the web3 spec. One way would be to require servers
to respect a 'Transfer-Encoding: chunked' header emitted by the
application. However, the WSGI and web3 specs specifically deny
this approach by saying, "Applications and middleware are forbidden
from using HTTP/1.1 "hop-by-hop" features or headers". A workaround
would be for the application to signal Transfer-Encoding by omitting
any Content-Length header in its response headers (this is what
CherryPy currently does).
6. I'd personally like to see it be OK for apps and middleware to
emit "Connection: close" too, or have some other way of
communicating
that desire to the server.
7. "it is presumed that Web3 middleware will be created which can
be used "in front" of existing WSGI 1.0 applications, allowing
those existing WSGI 1.0 applications to run under a Web3 stack.
This middleware will require, when under Python 3, an equivalence
to be drawn between Python 3 str types and the bytes values
represented by the HTTP request and all the attendant encoding-
guessing (or configuration) it implies." Just some field experience:
that's not hard. CherryPy 3.2 does this now between various WSGI
proposals.
Robert Brewer
fumanchu at aminus.org
More information about the Web-SIG
mailing list