On 07/14/2010 06:43 AM, Ian Bicking wrote:
There's only a couple tricky keys: SCRIPT_NAME, PATH_INFO,
and HTTP_COOKIE.
(And of those, PATH_INFO is the only one that really matters, in that
no-one really uses non-ASCII script filenames, and non-ASCII characters
in Cookie/Set-Cookie are still
On Friday, July 16, 2010, And Clover and...@doxdesk.com wrote:
On 07/14/2010 06:43 AM, Ian Bicking wrote:
There's only a couple tricky keys: SCRIPT_NAME, PATH_INFO,
and HTTP_COOKIE.
(And of those, PATH_INFO is the only one that really matters, in that no-one
really uses non-ASCII script
On 07/16/2010 12:07 PM, Graham Dumpleton wrote:
If you do that, one has to ask the question, given it is more convention than
anything, why it isn't just a x-wsgiorg extension specification
Yes, fine by me either way.
I just want to be able to say this application can use Unicode paths
when
At 11:07 AM 7/16/2010 -0500, Ian Bicking wrote:
And this doesn't help with Python 3: either we have byte values of
SCRIPT_NAME and PATH_INFO in Python 3, or we have text values. I
think bytes will be more awkward to port to than text, and
inconsistent with other WSGI values.
OTOH, it has
BTW, if you're a noob like me and can't follow the Unicode stuff,
I once read this:
http://www.joelonsoftware.com/articles/Unicode.html
I need to read it again before commenting, but I seem to recall it
being edifying, if not particularly memorable. ;-)
--
A Weapon of Mass Construction
My
On Friday, July 16, 2010, Ian Bicking wrote:
We could make everything bytes and be done with it, but it would make it
much harder to port Python 2 WSGI code to Python 3.
I think this might be best having seen all of the discussion. One could easily
write a compatibility middleware that makes
Hello,
Ian said:
Having two ways of expressing the same information will lead to bugs
related to which data is canonical. If an application is using
SCRIPT_NAME/PATH_INFO and then updates those values in any way, and
wsgi.raw_script_name/wsgi.raw_path_info are present, then there will be
On Fri, Jul 16, 2010 at 1:40 PM, P.J. Eby p...@telecommunity.com wrote:
At 11:07 AM 7/16/2010 -0500, Ian Bicking wrote:
And this doesn't help with Python 3: either we have byte values of
SCRIPT_NAME and PATH_INFO in Python 3, or we have text values. I think
bytes will be more awkward to
On Fri, Jul 16, 2010 at 5:08 PM, Chris McDonough chr...@plope.com wrote:
On Fri, 2010-07-16 at 17:47 -0400, Tres Seaver wrote:
In the past when we've gotten down to specifics, the only holdup has
been
SCRIPT_NAME/PATH_INFO, hence my suggestion to eliminate those.
I think I favor
On Fri, Jul 16, 2010 at 5:06 PM, Ian Bicking i...@colorstudy.com wrote:
On Fri, Jul 16, 2010 at 4:47 PM, Tres Seaver tsea...@palladion.comwrote:
Basically all the internal strings are textish, so we're left with:
What do you mean by internal? Anything in the headers or the CGI
On Fri, 2010-07-16 at 17:11 -0500, Ian Bicking wrote:
On Fri, Jul 16, 2010 at 5:08 PM, Chris McDonough chr...@plope.com
wrote:
On Fri, 2010-07-16 at 17:47 -0400, Tres Seaver wrote:
In the past when we've gotten down to specifics, the only
holdup has been
At 02:28 PM 7/16/2010 -0500, Ian Bicking wrote:
On Fri, Jul 16, 2010 at 1:40 PM, P.J. Eby
mailto:p...@telecommunity.comp...@telecommunity.com wrote:
At 11:07 AM 7/16/2010 -0500, Ian Bicking wrote:
And this doesn't help with Python 3: either we have byte values of
SCRIPT_NAME and PATH_INFO in
At 05:42 PM 7/16/2010 -0400, Tres Seaver wrote:
P.J. Eby wrote:
(Hm. Although actually, I suppose we *could* just borrow the time
machine and pretend that WSGI called for byte-strings everywhere
all along...)
I like the idea of pushing responsibility for decoding stuff into the
framework /
Hi,
On 7/17/10 1:20 AM, Chris McDonough wrote:
Let me know if I'm missing something.
The only thing you miss is that the bytes type of Python 3 is badly
supported in the stdlib (not an issue if we reimplement everything in
our libraries, not an issue for me) and that the bytes type has no
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
P.J. Eby wrote:
At 07:20 PM 7/16/2010 -0400, Chris McDonough wrote:
I'd much rather say be able to say:
The PATH_INFO environment variable is a ``bytes-with-benefits`` type.
To decode it:
- First, split it on slashes::
segments =
On Sat, 2010-07-17 at 01:33 +0200, Armin Ronacher wrote:
Hi,
On 7/17/10 1:20 AM, Chris McDonough wrote:
Let me know if I'm missing something.
The only thing you miss is that the bytes type of Python 3 is badly
supported in the stdlib (not an issue if we reimplement everything in
our
On Fri, Jul 16, 2010 at 8:46 PM, Ian Bicking i...@colorstudy.com wrote:
So... before jumping to conclusions, what's the hard part with using text?
Oh, the one thing that will be silly is cookies, but they are totally nuts
already. They can be parsed equally well as bytes or latin1, and best
On Saturday, July 17, 2010, Ian Bicking i...@colorstudy.com wrote:
On Fri, Jul 16, 2010 at 6:20 PM, Chris McDonough chr...@plope.com wrote:
What are the concrete problems you envision with text request headers,
text (URL-quoted) path, and text response status and headers?
Documentation is
On Fri, Jul 16, 2010 at 11:28 PM, Graham Dumpleton
graham.dumple...@gmail.com wrote:
Nah, not nearly that hard:
path_info =
urllib.parse.unquote_to_bytes(environ['wsgi.raw_path_info']).decode('UTF-8')
I don't see the problem? If you want to distinguish %2f from /, then
you'll do it
On Saturday, July 17, 2010, Ian Bicking i...@colorstudy.com wrote:
On Fri, Jul 16, 2010 at 4:33 AM, And Clover and...@doxdesk.com wrote:
On 07/14/2010 06:43 AM, Ian Bicking wrote:
There's only a couple tricky keys: SCRIPT_NAME, PATH_INFO,
and HTTP_COOKIE.
(And of those, PATH_INFO is
On Saturday, July 17, 2010, Ian Bicking i...@colorstudy.com wrote:
On Fri, Jul 16, 2010 at 12:28 PM, Chris McDonough chr...@plope.com wrote:
On Fri, 2010-07-16 at 11:07 -0500, Ian Bicking wrote:
And this doesn't help with Python 3: either we have byte values of
SCRIPT_NAME and PATH_INFO in
21 matches
Mail list logo
