[Web-SIG] PEP 444 (aka Web3)

[Robert Brewer]

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