Re: [Web-SIG] WSGI Amendments thoughts: the horror of charsets

[Mark Hammond]

> Python decodes the environ to its own copy (wrapped in os.environ) at
> interpreter startup time;

I don't think Python explicitly converts it - the CRT's ANSI version of environ 
is used, so the resulting strings should be encoded using the 'mbcs' encoding.  
What mangling do you see?

> there's no way to query the real ‘live’
> environment that I know of. It'd require a C extension.

win32api and ctypes would both let you call the Windows API.

> What I'm saying is that neither Apache's nor IIS's behaviour can be
> considered clearly correct or wrong at this point, and there is no way
> a WSGI adapter living underneath them *can* fix up the differences.

What is IIS doing wrong here?  IIUC, ISAPI treats everything as bytes, so it is 
more likely to be the "higher-level" layers built on ISAPI (eg, ASP) which 
assume encodings.

Apologies if you have already answered any of these - I haven’t been following 
that closely...

Cheers,

Mark

___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: 
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com

Re: [Web-SIG] Revising environ['wsgi.input'].readline in the WSGI specification

[Robert Brewer]

+1

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:web-sig-
> [EMAIL PROTECTED] On Behalf Of Ian Bicking
> Sent: Sunday, November 16, 2008 10:06 AM
> To: Graham Dumpleton
> Cc: Web SIG
> Subject: Re: [Web-SIG] Revising environ['wsgi.input'].readline in the
> WSGI specification
> 
> Graham Dumpleton wrote:
> > 2008/11/16 Ian Bicking <[EMAIL PROTECTED]>:
> >> We need to make a revision to the WSGI spec to say that
> >> environ['wsgi.input'].readline takes an optional size argument.  It
> always
> >> does in practice (except in wsgiref.validate.validator, rendering
> that
> >> validator useless), and is required to in practice, because
everyone
> uses
> >> cgi.FieldStorage, and it passes in that argument.
> >
> > This has been brought up numerous times before. There are other
> things
> > about wsgi.input that really need to be changed as well to make it
> > more useful. When I have pushed for revised specification before I
> > could never get enough interest in it from the people that most
would
> > perceive are the ones who oversee the PEP.
> 
> Yes, this has been passed over before.  To resolve this, let's just
not
> pass it over this time?  This is a relatively small change to the WSGI
> spec, because it represents standard practice -- this change is simply
> getting the spec in line with implementations.
> 
> --
> Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org
> ___
> Web-SIG mailing list
> Web-SIG@python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-
> sig/fumanchu%40aminus.org
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: 
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com

Re: [Web-SIG] Revising environ['wsgi.input'].readline in the WSGI specification

[Ian Bicking]

Graham Dumpleton wrote:

2008/11/16 Ian Bicking <[EMAIL PROTECTED]>:

We need to make a revision to the WSGI spec to say that
environ['wsgi.input'].readline takes an optional size argument.  It always
does in practice (except in wsgiref.validate.validator, rendering that
validator useless), and is required to in practice, because everyone uses
cgi.FieldStorage, and it passes in that argument.


This has been brought up numerous times before. There are other things
about wsgi.input that really need to be changed as well to make it
more useful. When I have pushed for revised specification before I
could never get enough interest in it from the people that most would
perceive are the ones who oversee the PEP.


Yes, this has been passed over before.  To resolve this, let's just not 
pass it over this time?  This is a relatively small change to the WSGI 
spec, because it represents standard practice -- this change is simply 
getting the spec in line with implementations.


--
Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: 
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com

[Web-SIG] possible bug in cgi

[Stephan Diehl]

this is probably not the right place to ask, but I found some irritating
behaviour with the cgi module and are unsure if it's a bug (seen on
python2.5 and python2.6)
The problem is this:
>>> import cgi
>>> cgi.FieldStorage(environ={'QUERY_STRING':u'a=b'})
FieldStorage(None, None, [MiniFieldStorage('a\x00', '\x00b\x00')])
>>> cgi.FieldStorage(environ={'QUERY_STRING':'a=b'})
FieldStorage(None, None, [MiniFieldStorage('a', 'b')])

When creating a FieldStorage with an environment that contains a unicode
'QUERY_STRING' value, garbage is returned.
The ultimate problem seems to be, that the QUERY_STRING is converted to
a cStringIO object which holds only the memory representation of unicode
strings.

Regards, Stephan
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: 
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com