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