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 fuman...@aminus.org _______________________________________________ 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