Re: [Web-SIG] Future of WSGI
2009/11/24 Ian Bicking i...@colorstudy.com: Why does this matter? It's all convention, but the CGI interpretation was to read the HTTP request line by line until a blank line came and that was the environment. Everything after that is the body. If you want to obtain a shorter call signature – e.g. (environ, start_response) instead of (environ, body, start_response), that's fine; but maybe this should be a decorator. You could take this argument further and do this in two steps (leaving out ``start_response`` in the following): (stream,) = (cgi_environ, body) = (hybrid_environ,) That would preserve all information. Why does it matter? This is the single most difficult question to answer in software design because it's a matter of balance. On the one hand we strive to find the best abstractions to express our problems which will eventually be serialized into one or more tracks of assembler code. On the other, we must be pragmatic and stop our quest in time to still get things done in reasonable time. I'm not sure the balance is in favor of the hybrid model; when you google environ http you don't see a lot of body input stream in there. You don't see multi-threading in there either; however, in the WSGI environment, you do! We just put it there, because we don't know where else to put it! Unable to find or respect the abtractions, we are lucky to have Python's versatile dictionary. The downside: bitrot. \malthe ___ 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
Re: [Web-SIG] Future of WSGI
2009/11/24 Henry Precheur he...@precheur.org: (See http://tools.ietf.org/html/rfc2616#section-5) The request body, the request method (GET, POST, ...), the request URL, the HTTP version are all in `environ`. That reference does not mention the environment. It's not an official term. If you really want to separate the headers from the rest you would put another dictionary containing the headers inside `environ`. Instead WSGI puts the headers prefixed with HTTP_ in `environ`, because that's what CGI is doing. It might not be 100% clean, or logic, but it's SIMPLER, there's no need to deal with nested dictionaries or other more complex structure, and it's extensible. I don't mind those. CGI does it too, like you say. namedtuple is Python 2.6+: WSGI can't use it. WSGI must work w/ older versions of Python. It was meant as illustration, but sure. \malthe ___ 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
Re: [Web-SIG] Move to bless Graham's WSGI 1.1 as official spec
On 12/4/09 12:50 AM, And Clover wrote: So for now there is basically nothing useful WSGI can do other than provide direct, byte-oriented (even if wrapped in 8859-1 unicode strings) access to headers. You could argue that this is perhaps a good reason to replace ``environ`` with something that interprets the headers according to how HTTP is actually used in the real world. It may be that WSGI should use bytes everywhere and the recommended usage would be via a decorator (which could cache computations on the environ dictionary): e.g. the raw application handler versus one decorated with an imaginary ``webob`` function. def app(environ, start_response): ... @webob def app(request): ... It is often said that WSGI should be practical, but in actual usage, I think most developers use a request/response abstraction layer. Middlewares are usually shrink-wrapped library code that could handle a bytes-based environ dict (they'd have to explicitly decode the headers of interest). \malthe ___ 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
Re: [Web-SIG] Future of WSGI
2009/11/26 And Clover and...@doxdesk.com: Whilst in principle I kind of agree with Malthe that keeping the CGI-derived environ separate from items like wsgi.input would be appropriate, in practice I don't give a stuff about it: the merged dictionary causes no practical problems, and changing it would be an enormous upheaval for all WSGI users. It will anyway (moving to Python 3). WSGI doesn't need to be pretty, it needs to be widely-compatible. Authors who want pretty can use frameworks, which will be happy to deliver elegant Request and Response objects. It's not about pretty more than PEP 8 is about pretty (hint: it's not). \malthe ___ 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
[Web-SIG] Future of WSGI
I disagree that the current 1.x track of the WSGI specification [1] supports Python 3 in any reasonable way. Recently I suggested the following rule as a guideline [2]: Strings should be strings, chunks should be bytes. What this really suggests is that everything that looks and feels like a human-readable string (almost everything in HTTP except the input content and the output response) should be a (unicode) string. As I read the proposed 1.1 revision, this is not the case. However, there is another fish to fry here too, and I'd like to propose a new 2.x track altogether. In the outset, this would pertain to Python 3 only. Instead of passing ``environ`` and violate its contract by adding 'wsgi.*' entries, we must pass in an object which actually represents the HTTP request, e.g. Request = namedtuple(Request, environ input) There could be other properties of this request-object. I haven't considered the details. To consider for this track is also the possibility of changing the application call signature (I heard this proposal from Daniel Holth, but it's probably been suggested before): def __call__(self, request): return status, headers, app_iter I don't mind ``start_response`` terribly, but it's worth discussing. Certainly returning this triple makes things easier. \malthe [1] http://bitbucket.org/ianb/wsgi-peps/src/tip/pep-0333.txt [2] http://mockit.blogspot.com/2009/11/dont-look-back-in-anger.html ___ 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
Re: [Web-SIG] Future of WSGI
2009/11/24 Henry Precheur he...@precheur.org: Are you talking about PEP-333 or RFC 2616? RFC 2616, which you linked to. Then what? Your proposal doesn't work. So let's forget about it and stick to dict? class Request(object): ... class Response(object): ... Now, what do you mean by let's forget about it. Maybe what you want to say is: I'll forget about it and stick to dict – because that's what you know how to? I mean this congenially; but please don't patronize. \malthe ___ 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
Re: [Web-SIG] Future of WSGI
2009/11/25 Henry Precheur he...@precheur.org: Please replace '...' with actual code or at least some description of what it's doing. Lots of people have been trying to define a nice interface for these objects for YEARS. People who know a great deal about HTTP, and Python. And yet there's not a single implementation that's widely accepted as the best of breed. class Request(object): def __init__(self, stream): self.environ = read_headers_until_crlf(stream) self.stream = stream These headers are then general-header, request-header, entity-header. The stream is what remains. Ian argues that the stream is part of the environment since ``CONTENT_LENGTH`` is there. However, it is not always there. It is to be understood as a hint. Why is this a good separation? For two reasons: 1) Everybody else does it; 2) This stream should be handled carefully throughout the WSGI pipeline. Keeping it as a separate property helps to make this point clear. As an alternative to a trivial request class, I propose: (environ, stream, [start_response]) (It seems ``start_response`` might go out altogether in a revised specification in favor of returning a response tuple over an app iterable). \malthe ___ 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
