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
Henry Precheur ha scritto:
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,
James Y Knight ha scritto:
I move to bless mod_wsgi's definition of WSGI 1.1 [1]
[...]
[1] http://code.google.com/p/modwsgi/wiki/SupportForPython3X
Hi.
Just a few questions.
It is true that HTTP headers can be encoded assuming latin-1; and they
can be encoded using PEP 383.
However what
Manlio Perillo wrote:
However what about URI (that is, for PATH_INFO and the like)?
For URI (if I remember correctly) the suggested encoding is UTF-8, so
URLS should be decoded using
url.decode('utf-8', 'surrogateescape')
Is this correct?
The currently-discussed proposal is
And Clover ha scritto:
[...]
Cookie data SHOULD be transparent to the server/gateway; however WSGI is
going to assume that data is encoded in latin-1.
Yeah. This is no big deal because non-ASCII characters in cookies are
already broken everywhere(*). Given this and other limitations on what
On Dec 3, 2009, at 1:35 PM, And Clover wrote:
Manlio Perillo wrote:
However what about URI (that is, for PATH_INFO and the like)?
For URI (if I remember correctly) the suggested encoding is UTF-8, so
URLS should be decoded using
url.decode('utf-8', 'surrogateescape')
Is this correct?
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
And Clover ha scritto:
Manlio Perillo wrote:
However what about URI (that is, for PATH_INFO and the like)?
For URI (if I remember correctly) the suggested encoding is UTF-8, so
URLS should be decoded using
url.decode('utf-8', 'surrogateescape')
Is this correct?
The
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,
Manlio Perillo wrote:
Words of *TEXT MAY contain characters from character sets other than
ISO-8859-1 [22] only when encoded according to the rules of RFC 2047
Yeah, this is, unfortunately, a lie. The rules of RFC 2047 apply only to
RFC*822-family 'atoms' and not elsewhere; indeed, RFC2047
Graham Dumpleton wrote:
Answering my own question, it is actually obvious that it has to be
called (1, 0). This is because wsgiref in Python 3.X already calls it
(1, 0) and don't have much choice to be in agreement with that.
wsgiref.simple_server in Python 3 to date is not something that
After reading my prior blog posts where I explained my reasoning
behind the changes, I will acknowledge that I haven't explained some
stuff very well and people are failing to understand or getting wrong
idea about why something is being suggested.
I still believe there are though underlying
On Nov 28, 2009, at 10:44 PM, Graham Dumpleton wrote:
Either way, since there seemed to be objections at some level on every
point, and since I really really have no enthusiasm for this stuff any
more or of fighting for any change, I retract my personal interest in
having any of the amendments
2009/11/29 James Y Knight f...@fuhm.net:
On Nov 28, 2009, at 10:44 PM, Graham Dumpleton wrote:
Either way, since there seemed to be objections at some level on every
point, and since I really really have no enthusiasm for this stuff any
more or of fighting for any change, I retract my personal
I second the move, recorded here:
http://listtree.appspot.com/wsgi2/ICvaujouPxb2gfEhDS_aiw
-- Aaron Watters
--- On Thu, 11/26/09, James Y Knight f...@fuhm.net wrote:
From: James Y Knight f...@fuhm.net
Subject: [Web-SIG] Move to bless Graham's WSGI 1.1 as official spec
To: Web SIG web-sig
At 08:42 PM 11/26/2009 -0500, James Y Knight wrote:
I move to bless mod_wsgi's definition of WSGI 1.1 [1] as the
official definition of WSGI 1.1, which describes how to implement
WSGI adapters for both Python 2.x and 3.x. It may not be perfect,
but, it's been implemented twice, and seems ot
At 12:34 PM 11/27/2009 -0500, James Y Knight wrote:
On Nov 27, 2009, at 10:20 AM, P.J. Eby wrote:
Second, I do not think that the additional
guarantees/requirements can be safely added to a 1.x version, as
they make it impossible for an app to tell whether it's *really*
running under 1.1 or
On Fri, Nov 27, 2009 at 12:20 PM, P.J. Eby p...@telecommunity.com wrote:
1. The 'readline()' function of 'wsgi.input' may optionally take a size
hint.
Already de-facto required. Leaving it out helps no-one. KEEP.
Fair enough, since it's a MAY. On the other hand, because it's a MAY, it
Please ensure you have also all read:
http://blog.dscpl.com.au/2009/10/details-on-wsgi-10-amendmentsclarificat.html
I will post again later in detail when have some time to explain a few
more points not mentioned in that post and where people aren't quite
understanding the reasoning for doing
I move to bless mod_wsgi's definition of WSGI 1.1 [1] as the official
definition of WSGI 1.1, which describes how to implement WSGI adapters for both
Python 2.x and 3.x. It may not be perfect, but, it's been implemented twice,
and seems ot have no fatal flaws (it doesn't do any lossy
20 matches
Mail list logo
