On Wed, Aug 12, 2009 at 12:05:40AM -0500, Ian Bicking wrote:
Correct -- you can write any set of % encodings, and I don't think it even
has to be able to validly url-decode (e.g., /foo%zzz will work). It
definitely doesn't have to be a valid encoding. However, if you actually
include unicode
On Sun, Aug 16, 2009 at 08:06:03PM -0700, Robert Brewer wrote:
However, we quite often use only a portion of the URI when attempting
to locate an appropriate handler; sometimes just the leading /
character! The remaining characters are often passed as function
arguments to the handler, or
On Mon, Sep 21, 2009 at 11:09:24AM -0500, Ian Bicking wrote:
I think surrogateescape can resolve the small handful of problems.
+1
surrogateescape would be a great alternative to the try utf-8 then
latin-1 approach. It would simplify the gateway and the application. No
need to check some
On Mon, Sep 21, 2009 at 09:14:13PM +0200, Armin Ronacher wrote:
So the same standard should have different behavior on different Python
versions? That would make framework code a lot more complicated.
I don't understand why it would be 'a lot more' complicated.
(The following code snippets is
On Mon, Sep 21, 2009 at 03:26:35PM -0700, Robert Brewer wrote:
It looks simpler until you have a site that is not primarily utf-8. In
that case, you multiply your (1 line * number of middlewares in the WSGI
stack * each request).
With wsgi.uri_encoding you get either (1 line * 1
middleware
On Mon, Sep 21, 2009 at 07:40:54PM -0700, Robert Brewer wrote:
The decoding doesn't change spontaneously.
You either get the correct one or you get an incorrect one. If it's
incorrect, you fix it, one time, via a WSGI component which you've
configured to determine the correct decoding. Then
On Tue, Sep 22, 2009 at 11:26:15PM -0400, P.J. Eby wrote:
+1, if you mean the strings have the same content,
character-for-character on Python 2.3. That is, a \x80 byte in a
Python 2 'str' is matched by an \x80 character in the Python 3
'str'. (I presume that's what we mean by native, but
On Tue, Sep 22, 2009 at 09:22:48PM -0500, Ian Bicking wrote:
Well, the biggie: is it right to use native strings for the environ values,
and response status/headers? Specifically, tricks like the latin1
transcoding won't work in Python 2, but will in Python 3. Is this weird?
Or just
On Sun, May 31, 2009 at 09:30:26AM -0700, Omar Munk wrote:
- A good documentation.
- Not to overkill like Django
- Easy and simple
- Just something like PHP but without the dirty style.
- I like Karrigell but it looks like it's dead do you know a clone of it?
- Not need a
On Tue, Nov 24, 2009 at 11:36:57PM +0100, Malthe Borch wrote:
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
On Tue, Nov 24, 2009 at 11:16:05PM +0100, Sylvain Hellegouarch wrote:
Though it shouldn't be considered as a problem, the fact that probably
no existing framework actually use the raw dictionary (there is, in
almost all cases, a wrapping into a friendlier object), one might wonder
why
On Thu, Dec 03, 2009 at 07:35:14PM +0100, And Clover wrote:
I don't know what the HTTP/Cookie spec says about this.
The traditional interpretation of RFC2616 is that headers are ISO-8859-1.
You will notice that no browser correctly follows this.
The RFC 2109 2965 say that a cookie's value
On Thu, Dec 03, 2009 at 05:09:31PM +0100, Manlio Perillo wrote:
This is really a mess.
RFC 2617 doesn't specify any encoding for its headers, so it should be
latin-1 everywhere. But on the web nobody respect standards.
How is authorization username handled in common WSGI frameworks?
As far as
On Thu, Dec 03, 2009 at 08:33:19PM +0100, Manlio Perillo wrote:
Right now I'm doing a: username.decode('us-ascii', 'replace')
Or like most frameworks you could let the application author deal with
the problem, just pass the raw strings to the application.
--
Henry Prêcheur
On Thu, Dec 03, 2009 at 09:15:06PM +0100, Manlio Perillo wrote:
There is something that I don't understand.
Some HTTP headers, like Accept-Language, contains data described as
`token`, where:
token = 1*any CHAR except CTLs or separators
So a token, IMHO, is an opaque string,
On Sun, Dec 20, 2009 at 11:38:19PM +0530, Senthil Kumaran wrote:
I need your opinion on this request.
http://bugs.python.org/issue1673007
Python Standard Library module urllib2 has support GET and POST.
There was a feature request to add support for HEAD requests.
It would be nice to have
On Tue, Nov 24, 2009 at 10:50:00PM +0100, Malthe Borch wrote:
How people use or abuse software is not our concern; but the standard
library should not itself abuse its own abstractions.
Your assumption is that `environ` == HTTP headers. That's simply NOT the
case. A request is:
- A request
17 matches
Mail list logo
