Re: [Web-SIG] bytes / unicode

On Wed, Jun 23, 2010 at 09:36:45PM +0200, Antoine Pitrou wrote: > I don't think you can't claim, though, that Python 3 makes things > significantly harder for these frameworks. The proof is that many of > them already give the user unicode strings in Python 2.x. They must > have somehow got the dec

Re: [Web-SIG] Future of WSGI

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 reques

Re: [Web-SIG] [RFC] urllib2 requests history + HEAD support

On Sun, Dec 20, 2009 at 11:38:19PM +0530, Senthil Kumaran wrote: > I need your opinion on this request. > > > 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

Re: [Web-SIG] Move to bless Graham's WSGI 1.1 as official spec

On Fri, Dec 04, 2009 at 07:40:55PM +0100, Manlio Perillo wrote: > What are the functions that does not works with byte strings? Just to make things clear, I was talking about Python 3. All the functions I tried not ending with _from_bytes raise an exception with bytes. This includes urllib.parse.

Re: [Web-SIG] Move to bless Graham's WSGI 1.1 as official spec

On Fri, Dec 04, 2009 at 10:17:09AM +0100, Manlio Perillo wrote: > It is just as simple as using byte strings, IMHO. No, it's not. There were lots of dicussions regarding this on the mailing list. One of the main issue is that the standard library supports bytes poorly. urllib for example expects s

Re: [Web-SIG] Move to bless Graham's WSGI 1.1 as official spec

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* > > So a token, IMHO, is an opaque string, and it SHOULD not decoded. >

Re: [Web-SIG] HTTP headers encoding

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 __

Re: [Web-SIG] HTTP headers encoding

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 a

Re: [Web-SIG] Move to bless Graham's WSGI 1.1 as official spec

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

Re: [Web-SIG] Future of WSGI

On Tue, Nov 24, 2009 at 11:57:08PM +0100, Malthe Borch wrote: > 2009/11/24 Henry Precheur : > > Are you talking about PEP-333 or RFC 2616? > > RFC 2616, which you linked to. Environment is not an 'official' term in RFC 2616, because it's about HTTP, not WSGI.

Re: [Web-SIG] Future of WSGI

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 ke

Re: [Web-SIG] Future of WSGI

On Tue, Nov 24, 2009 at 11:36:57PM +0100, Malthe Borch wrote: > 2009/11/24 Henry Precheur : > > (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`. &

Re: [Web-SIG] Web Framework

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 nee

Re: [Web-SIG] Proposal to remove SCRIPT_NAME/PATH_INFO

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 somet

Re: [Web-SIG] Proposal to remove SCRIPT_NAME/PATH_INFO

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"

Re: [Web-SIG] Request for Comments on upcoming WSGI Changes

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. Th

Re: [Web-SIG] Request for Comments on upcoming WSGI Changes

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

Re: [Web-SIG] Request for Comments on upcoming WSGI Changes

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 i

Re: [Web-SIG] Request for Comments on upcoming WSGI Changes

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 'enc

Re: [Web-SIG] Unicode in Python 3

On Sat, Sep 19, 2009 at 07:14:23PM +0100, René Dudfield wrote: > Yes, I think the callables will need a set method... rather than > letting the middleware replace callables. > > I think this could be used for middleware: > environ['SCRIPT_NAME'](set = "/bla/", urldecoding = False, encoding > ='

Re: [Web-SIG] WSGI 2: Decoding the Request-URI

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

Re: [Web-SIG] WSGI 2

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 unic

Re: [Web-SIG] WSGI 2

On Wed, Aug 12, 2009 at 09:25:21AM +1000, Graham Dumpleton wrote: > Use of bytes everywhere can be inconvenient on the gateway/server > side, at least as far as end result for user. Yes, but wouldn't it be simpler for mod_wsgi to only deal with bytes? unicode C strings -> bytes and char* -> bytes

Re: [Web-SIG] WSGI 2

Using bytes for all `environ` values is easy to understand on the application side as long as you are aware of the encoding problem. The cost is inconvenience, but that's probably OK. It's also simpler to implement on the gateway/server side. By choosing bytes, WSGI passes the encoding problem to