On May 8, 2009, at 6:58 PM, P.J. Eby wrote:
Hell if I know. I'm just explaining (possibly incorrectly) why the
consensus went that way last time we discussed it here... a
consensus that I thought you were part of actually, but maybe my
memory is faulty. (Hell, it happened so long ago that
At 06:05 PM 5/8/2009 -0400, James Y Knight wrote:
On May 8, 2009, at 6:00 PM, P.J. Eby wrote:
Compatibility sometimes demands we do silly things. Personally, I
think it's kind of silly that Python 3 files return incompatible
data types depending on what mode you open them in, but there's not
a
On May 8, 2009, at 6:00 PM, P.J. Eby wrote:
Compatibility sometimes demands we do silly things. Personally, I
think it's kind of silly that Python 3 files return incompatible
data types depending on what mode you open them in, but there's not
a whole lot we can do about that.
Meanwhile, e
At 02:39 PM 5/8/2009 -0400, James Y Knight wrote:
On May 8, 2009, at 1:37 PM, Robert Brewer wrote:
If Python3 WSGI apps emit unicode strings (py3k type 'str'), you're
effectively saying the server will always call
"chunk.encode('latin-1')". That negates any benefit of using unicode
as
the type f
At 10:37 AM 5/8/2009 -0700, Robert Brewer wrote:
It also explicitly states that "HTTP does not directly support Unicode,
and neither does this interface. All encoding/decoding must be handled
by the application; all strings passed to or from the server must be
standard Python BYTE STRINGS (emphas
On May 8, 2009, at 1:37 PM, Robert Brewer wrote:
If Python3 WSGI apps emit unicode strings (py3k type 'str'), you're
effectively saying the server will always call
"chunk.encode('latin-1')". That negates any benefit of using unicode
as
the type for the response. That's not "supporting unicode";
P.J. Eby wrote:
> At 08:07 AM 5/8/2009 -0700, Robert Brewer wrote:
>> I decided that that single type should be byte strings because I want
>> WSGI middleware and applications to be able to choose what encoding
>> their output is. Passing unicode to the server would require some
>> out-of-band meth
At 08:07 AM 5/8/2009 -0700, Robert Brewer wrote:
I decided that that single type should be byte strings because I want
WSGI middleware and applications to be able to choose what encoding
their output is. Passing unicode to the server would require some
out-of-band method of telling the server whi
Graham Dumpleton wrote:
> Robert, do you have any comments on the restricting of response
> content to bytes and not allow fallback to conversion per latin-1?
>
> I heard that in CherryPy WSGI server you are only allowing bytes. What
> is your rational for that at the moment?
In Python 2.x, one
2009/5/5 Graham Dumpleton
>>> Now, if we are going to start using bytes for request headers, there
>>> is the other question of response data.
>>>
>>> The original proposal in amendments was that application should
>>> provide bytes, but that WSGI adapter must accept either bytes or
>>> strings, w
On Tue, May 5, 2009 at 10:14 PM, Graham Dumpleton <
graham.dumple...@gmail.com> wrote:
> 2009/5/6 Ian Bicking :
> > Philip Jenvey brought this to my attention:
> >
> > http://www.python.org/dev/peps/pep-0383/
> >
> > It's a UTF8 encoding and decoding scheme that encodes illegal bytes in
> such
>
2009/5/6 Ian Bicking :
> Philip Jenvey brought this to my attention:
>
> http://www.python.org/dev/peps/pep-0383/
>
> It's a UTF8 encoding and decoding scheme that encodes illegal bytes in such
> a way that you can decode to get the original bytes object, and thus
> transcode to another encoding.
Philip Jenvey brought this to my attention:
http://www.python.org/dev/peps/pep-0383/
It's a UTF8 encoding and decoding scheme that encodes illegal bytes in such
a way that you can decode to get the original bytes object, and thus
transcode to another encoding. It's intended for cases exactly l
Graham Dumpleton wrote:
> 2009/5/5 Armin Ronacher :
>> Graham Dumpleton wrote:
>>> I can't see but have choice but to pass such settings through as
>>> strings, else more than likely would cause problems for applications.
>>> Problem is it isn't clear what encoding stuff can be in Apache
>>> config
2009/5/5 Armin Ronacher :
> Hi,
>
> Graham Dumpleton wrote:
>> I can't see but have choice but to pass such settings through as
>> strings, else more than likely would cause problems for applications.
>> Problem is it isn't clear what encoding stuff can be in Apache
>> configuration. At the moment
2009/5/5 Armin Ronacher :
> Hello everybody,
>
> I just recently started looking at supporting Python 3 with one of my
> libraries
> (Werkzeug), mainly because the MoinMoin projects considers using it which uses
> the library in question. Right now what Werkzeug does is consider HTTP being
> Unic
Hello everybody,
I just recently started looking at supporting Python 3 with one of my libraries
(Werkzeug), mainly because the MoinMoin projects considers using it which uses
the library in question. Right now what Werkzeug does is consider HTTP being
Unicode aware in the sense that everything t
On Fri, 2009-04-17 at 09:37 +1000, Graham Dumpleton wrote:
> >> I am not sure we ended up with a final answer on all of this, but I
> >> don't want to hold up mod_wsgi 3.0, which includes Python 3.0 support,
> >> any longer. As such, am implementing things as per:
> >>
> >> http://www.wsgi.org/ws
2009/4/17 Robert Brewer :
> On Thu, 2009-04-16 at 00:12 -0700, Graham Dumpleton wrote:
>> > So, from where I sit, we have:
>> >
>> > 1. Many header values which are ASCII.
>> > 2. A few header values which are ISO-8859-1 plus RFC 2047.
>> > 3. A few header values which are URI's (no specified en
On Fri, Apr 17, 2009 at 02:03, Graham Dumpleton
wrote:
> 2009/4/17 James Y Knight :
>> On Apr 16, 2009, at 3:12 AM, Graham Dumpleton wrote:
>>>
>>> I am not sure we ended up with a final answer on all of this, but I
>>> don't want to hold up mod_wsgi 3.0, which includes Python 3.0 support,
>>> any
2009/4/17 James Y Knight :
> On Apr 16, 2009, at 3:12 AM, Graham Dumpleton wrote:
>>
>> I am not sure we ended up with a final answer on all of this, but I
>> don't want to hold up mod_wsgi 3.0, which includes Python 3.0 support,
>> any longer. As such, am implementing things as per:
>>
>> http://
On Apr 16, 2009, at 3:12 AM, Graham Dumpleton wrote:
I am not sure we ended up with a final answer on all of this, but I
don't want to hold up mod_wsgi 3.0, which includes Python 3.0 support,
any longer. As such, am implementing things as per:
http://www.wsgi.org/wsgi/Amendments_1.0
with excep
On Thu, 2009-04-16 at 00:12 -0700, Graham Dumpleton wrote:
> > So, from where I sit, we have:
> >
> > 1. Many header values which are ASCII.
> > 2. A few header values which are ISO-8859-1 plus RFC 2047.
> > 3. A few header values which are URI's (no specified encoding) or
> IRI's
> > (UTF-8).
>
2009/4/4 Robert Brewer :
> Alan Kennedy wrote:
>> [Bill]
>> > I think the controlling reference here is RFC 3875.
>>
>> I think the controlling references are RFC 2616, RFC 2396 and RFC
> 3987.
>>
>> RFC 2616, the HTTP 1.1 spec, punts on the question of character
>> encoding for the request URI.
>>
Probably of interest in regards to this discussion:
http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0057.html
http://trac.tools.ietf.org/wg/httpbis/trac/ticket/63
This applies to headers but probably shows that RFC 2047 is gradually
ruled out of HTTP.
- Sylvain
--
Sylvain Hellegouar
> ... The Request-URI needs to handle IRI's. The headers mostly
> don't--almost all headers are of mostly type "token", which is US-ASCII.
> A few are of type "TEXT", which is ISO-8859-1/RFC 2047. The remaining
> (sub)values are mostly custom byte sequences: ...
Also don't forget about the still-i
James Y Knight wrote:
> On Apr 2, 2009, at 7:33 AM, Graham Dumpleton wrote:
>
> > """When running under Python 3, servers MUST provide CGI HTTP
> > variables as strings, decoded from the headers using HTTP standard
> > encodings (i.e. latin-1 + RFC 2047)"""
> >
> > Which is fair enough and basical
Graham Dumpleton wrote:
> I am slowly working through what I think I at least need to do for
> Apache/mod_wsgi. I'll give a summary of what I have worked out so far
> based on the discussions and my own research.
> ...
> Next HTTP header to worry about is HTTP_REFERRER.
>
> There would be two part
Alan Kennedy wrote:
> [Bill]
> > I think the controlling reference here is RFC 3875.
>
> I think the controlling references are RFC 2616, RFC 2396 and RFC
3987.
>
> RFC 2616, the HTTP 1.1 spec, punts on the question of character
> encoding for the request URI.
>
> RFC 2396, the URI spec, says
>
At 07:51 AM 4/2/2009 +1100, Graham Dumpleton wrote:
If we are going to carry values in two different formats,
Let's try not to do that, either. ;-)
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
Bill Janssen wrote:
> Alan Kennedy wrote:
> > [Bill]
> > > I think the controlling reference here is RFC 3875.
> >
> > I think the controlling references are RFC 2616, RFC 2396
> > and RFC 3987.
>
> I see what you're saying, but it's darn near impossible, as a
practical
> matter, to get any guida
2009/4/3 Tres Seaver :
>> DOCUMENT_ROOT: '/Library/WebServer/Documents'
>> SCRIPT_FILENAME: '/Users/grahamd/Sites/echo.wsgi'
>>
>> These are file system paths, and since the Apache Runtime Library used
>> for Apache 2.X has a define for whether file system supports unicode,
>> can say:
>>
>> #if
2009/4/3 James Y Knight :
>
> On Apr 2, 2009, at 1:40 PM, Tres Seaver wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> James Y Knight wrote:
>>>
>>> On Apr 2, 2009, at 7:33 AM, Graham Dumpleton wrote:
>>>
"""When running under Python 3, servers MUST provide CGI HTTP
vari
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
James Y Knight wrote:
> On Apr 2, 2009, at 2:33 PM, Tres Seaver wrote:
>> I don't understand why: if RFC2047 values are being passed as HTTP
>> headers, then surely the server has enough information to decode them,
>> and to ensure that they are re-en
On Apr 2, 2009, at 2:33 PM, Tres Seaver wrote:
I don't understand why: if RFC2047 values are being passed as HTTP
headers, then surely the server has enough information to decode them,
and to ensure that they are re-encoded into the same encoding as all
other WSGI enviornment variables (under Py
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
James Y Knight wrote:
> I think you're saying you agree with exactly the opposite of what I
> meant. The server/gateway (aka apache mod_wsgi) *must not* be required
> to handle RFC2047 decoding. Only the application (or a header parsing
> library that
On Apr 2, 2009, at 1:40 PM, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
James Y Knight wrote:
On Apr 2, 2009, at 7:33 AM, Graham Dumpleton wrote:
"""When running under Python 3, servers MUST provide CGI HTTP
variables as strings, decoded from the headers using HTTP stan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
James Y Knight wrote:
> On Apr 2, 2009, at 7:33 AM, Graham Dumpleton wrote:
>
>> """When running under Python 3, servers MUST provide CGI HTTP
>> variables as strings, decoded from the headers using HTTP standard
>> encodings (i.e. latin-1 + RFC 2047)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Graham Dumpleton wrote:
> 2009/4/2 Graham Dumpleton :
>> Is there going to be any simple answer to all of this? :-(
>
> I am slowly working through what I think I at least need to do for
> Apache/mod_wsgi. I'll give a summary of what I have worked out
On Apr 2, 2009, at 7:33 AM, Graham Dumpleton wrote:
"""When running under Python 3, servers MUST provide CGI HTTP
variables as strings, decoded from the headers using HTTP standard
encodings (i.e. latin-1 + RFC 2047)"""
Which is fair enough and basically what the RFCs say. At the moment I
don't
[Sylvain]
> Would there be any interest in asking the HTTP-BIS working group [1] what
> they think about it?
>
> Currently I couldn't find anything in their drafts suggesting they had
> decided to clarify this issue from a protocol's perspective but they might
> consider it to be relevant to their
2009/4/2 Graham Dumpleton :
> Is there going to be any simple answer to all of this? :-(
I am slowly working through what I think I at least need to do for
Apache/mod_wsgi. I'll give a summary of what I have worked out so far
based on the discussions and my own research.
Just so I have a list of
[Sylvain]
> Would there be any interest in asking the HTTP-BIS working group [1] what
> they think about it?
>
> Currently I couldn't find anything in their drafts suggesting they had
> decided to clarify this issue from a protocol's perspective but they might
> consider it to be relevant to their
Hi All,
> Is there going to be any simple answer to all of this? :-(
>
Would there be any interest in asking the HTTP-BIS working group [1] what
they think about it?
Currently I couldn't find anything in their drafts suggesting they had
decided to clarify this issue from a protocol's perspective
2009/4/2 Bill Janssen :
> Alan Kennedy wrote:
>
>> Hi Bill,
>>
>> [Bill]
>> > I think the controlling reference here is RFC 3875.
>>
>> I think the controlling references are RFC 2616, RFC 2396 and RFC 3987.
>
> I see what you're saying, but it's darn near impossible, as a practical
> matter, to g
Alan Kennedy wrote:
> Hi Bill,
>
> [Bill]
> > I think the controlling reference here is RFC 3875.
>
> I think the controlling references are RFC 2616, RFC 2396 and RFC 3987.
I see what you're saying, but it's darn near impossible, as a practical
matter, to get any guidance on encoding matters
At 10:11 AM 4/2/2009 +1100, Graham Dumpleton wrote:
Seems to me that you can't have it be configurable and it must always
be latin-1 interpretation. The problem is where you are composing
multiple WSGI applications. If they each have different expectations
or requirements as to how it is handled,
2009/4/2 Robert Brewer :
> Graham Dumpleton wrote:
>> 2009/4/2 Robert Brewer :
>> > Alan Kennedy wrote:
>> >> Hi Graham,
>> >>
>> >> I think yours is a good solution to the problem.
>> >>
>> >> [Graham]
>> >> > In other words, leave all the existing CGI variables to come
>> through
>> >> > as latin
Graham Dumpleton wrote:
> 2009/4/2 Robert Brewer :
> > Alan Kennedy wrote:
> >> Hi Graham,
> >>
> >> I think yours is a good solution to the problem.
> >>
> >> [Graham]
> >> > In other words, leave all the existing CGI variables to come
> through
> >> > as latin-1 decode
> >>
> >> As latin-1 or rfc
Hi Bill,
[Bill]
> I think the controlling reference here is RFC 3875.
I think the controlling references are RFC 2616, RFC 2396 and RFC 3987.
RFC 2616, the HTTP 1.1 spec, punts on the question of character
encoding for the request URI.
RFC 2396, the URI spec, says
"""
It is expected that a
2009/4/2 Robert Brewer :
> Alan Kennedy wrote:
>> Hi Graham,
>>
>> I think yours is a good solution to the problem.
>>
>> [Graham]
>> > In other words, leave all the existing CGI variables to come through
>> > as latin-1 decode
>>
>> As latin-1 or rfc-2047 decoded, to unicode.
>>
>> > and do anythi
Graham Dumpleton wrote:
> Has anyone actually got an example of code for doing RFC-2047
> decoding. Are there even any systems which make use of that encoding
> for web requests anyway. I still haven't really addressed that
> decoding requirement and I haven't seen any existing Python web stuff
> t
Alan Kennedy wrote:
> Hi Graham,
>
> I think yours is a good solution to the problem.
>
> [Graham]
> > In other words, leave all the existing CGI variables to come through
> > as latin-1 decode
>
> As latin-1 or rfc-2047 decoded, to unicode.
>
> > and do anything new in 'wsgi' variable namespac
2009/4/2 Alan Kennedy :
> Hi Graham,
>
> I think yours is a good solution to the problem.
>
> [Graham]
>> In other words, leave all the existing CGI variables to come through
>> as latin-1 decode
>
> As latin-1 or rfc-2047 decoded, to unicode.
Has anyone actually got an example of code for doing R
Hi Graham,
I think yours is a good solution to the problem.
[Graham]
> In other words, leave all the existing CGI variables to come through
> as latin-1 decode
As latin-1 or rfc-2047 decoded, to unicode.
> and do anything new in 'wsgi' variable namespace,
So the server provides
"wsgi.server_d
On Wed, Apr 1, 2009 at 3:37 PM, P.J. Eby wrote:
> At 01:09 PM 4/1/2009 -0700, Guido van Rossum wrote:
>>
>> Well you could make the bytes versions available under different keys.
>> I think you do something a bit similar this in webob, e.g. req.params
>> vs. req.str_params. (Perhaps you could have
At 01:09 PM 4/1/2009 -0700, Guido van Rossum wrote:
Well you could make the bytes versions available under different keys.
I think you do something a bit similar this in webob, e.g. req.params
vs. req.str_params. (Perhaps you could have QUERY_STRING and
QUERY_BYTES.) The decode() call used to cre
Graham Dumpleton wrote:
> 2009/4/2 Guido van Rossum :
> > On Wed, Apr 1, 2009 at 12:15 PM, Ian Bicking
> wrote:
> >> On Wed, Apr 1, 2009 at 11:34 AM, Guido van Rossum
> wrote:
> >>> On Wed, Apr 1, 2009 at 5:18 AM, Robert Brewer
> wrote:
> Good timing. We had been thinking to make everything
2009/4/2 Guido van Rossum :
> On Wed, Apr 1, 2009 at 12:15 PM, Ian Bicking wrote:
>> On Wed, Apr 1, 2009 at 11:34 AM, Guido van Rossum wrote:
>>> On Wed, Apr 1, 2009 at 5:18 AM, Robert Brewer wrote:
Good timing. We had been thinking to make everything strings except for
SCRIPT_NAME, PA
On Wed, Apr 1, 2009 at 12:15 PM, Ian Bicking wrote:
> On Wed, Apr 1, 2009 at 11:34 AM, Guido van Rossum wrote:
>> On Wed, Apr 1, 2009 at 5:18 AM, Robert Brewer wrote:
>>> Good timing. We had been thinking to make everything strings except for
>>> SCRIPT_NAME, PATH_INFO, and QUERY_STRING, since t
On Wed, Apr 1, 2009 at 11:34 AM, Guido van Rossum wrote:
> On Wed, Apr 1, 2009 at 5:18 AM, Robert Brewer wrote:
>> Good timing. We had been thinking to make everything strings except for
>> SCRIPT_NAME, PATH_INFO, and QUERY_STRING, since these few are pulled
>> from the Request-URI, which may be
Guido van Rossum wrote:
> On Wed, Apr 1, 2009 at 5:18 AM, Robert Brewer wrote:
> > Good timing. We had been thinking to make everything strings except for
> > SCRIPT_NAME, PATH_INFO, and QUERY_STRING, since these few are pulled
> > from the Request-URI, which may be in any encoding. It was thoug
Guido van Rossum wrote:
> Sent: Wednesday, April 01, 2009 9:34 AM
> To: Robert Brewer
> Cc: Web SIG
> Subject: Re: [Web-SIG] Python 3.0 and WSGI 1.0.
>
> On Wed, Apr 1, 2009 at 5:18 AM, Robert Brewer
> wrote:
> > Good timing. We had been thinking to make ever
On Wed, Apr 1, 2009 at 5:18 AM, Robert Brewer wrote:
> Good timing. We had been thinking to make everything strings except for
> SCRIPT_NAME, PATH_INFO, and QUERY_STRING, since these few are pulled
> from the Request-URI, which may be in any encoding. It was thought that
> the app would be best-qu
Graham Dumpleton wrote:
> Based on any discussions at PyCon, can someone give a summary of any
> conclusions drawn about how WSGI 1.0 should be implemented in Python
> 3.0.
>
> The previous analysis of this is at:
>
> http://www.wsgi.org/wsgi/Amendments_1.0
>
> I realise it may be work in prog
65 matches
Mail list logo
