[Web-SIG] PEP 444 (aka Web3)

[Armin Ronacher]

Hi,

On 9/16/10 6:19 PM, Robert Brewer wrote:
>   1. Hooray for all-byte output.
Hooray for agreeing :)

>   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.
I suppose it makes sense to word the spec in that order then, seems like 
the majority wants it that way round.

>   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.
I was toying with the idea to have a websocket extension for web3 which 
would have solved my usecase for requests without a content-length 
header.  The problem with the content length of incoming data is quite 
complex and that seemed to be the solution that was easiest for 
everybody involved.

>   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).
I am fine improving that, but it would require a very good reference 
implementation with enough comments so that people have an idea of how 
it's supposed to behave.  wsgiref is nice in WSGI already, but it has 
its faults to which we should try to keep in mind for web3.  (Like that 
it sets multithreaded flag despite being single threaded or that it 
always appends a Date header breaking some applications).

>   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.
I would like to see this feature as well, but you will have to fight for 
this feature with Phillip and Graham I suppose.

>   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.
I suppose we will see some adapters that have some configuration 
parameters to adapt to different usage patterns.


Regards,
Armin