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
_______________________________________________
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
