Re: [Web-SIG] resources for porting wsgi apps from python 2 to 3

or encoded if not bytes? I don't think it's specified by the PEP, but wsgiref looks like it'll chuck TypeError when it tries to write str to the buffer/socket. cheers, -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/ gtalk:chat?jid=bobi...@gmail.com

Re: [Web-SIG] wsgiref 0.2 dev in svn w/PEP 3333 support

but needs reverse-decoding on POSIX. Currently I use utf-8 and surrogateescape, but for Python 3.2 presumably os.environb will be the safer bet. -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/ ___ Web-SIG mailing list Web-SIG@python.org Web SIG

Re: [Web-SIG] Most WSGI servers close connections to early.

out a debugging page before the form-reading library has had a chance to consume the input. -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/ ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe

Re: [Web-SIG] PEP 444 (aka Web3)

. There are others, eg. Authorization. Anyway: folding doesn't happen in the HTTP world. It can be forgotten about. -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/ ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org

Re: [Web-SIG] PEP 444 (aka Web3)

with the hacks. Frameworks and libraries further up the stack cannot reliably do the fixups, because they don't know whether the WSGI environ they have been given comes from os.environ or somewhere else, or whether middleware has played with it. -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com

Re: [Web-SIG] PEP 444 (aka Web3)

simply cannot rely on it. chr...@plope.com wrote: The most sensible thing to me would be to put it in PATH_INFO. Please don't have a field with encoded semantics that re-uses the name of a field that has always had decoded semantics. -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com

Re: [Web-SIG] WSGI for Python 3

ctypes envvar hacking. But if the server/gateway has good raw paths it shouldn't bother use these.) -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/ ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig

Re: [Web-SIG] WSGI for Python 3

run on a server/gateway that supports standardised feature X, rather than the current mess of you can have Unicode paths if you use one of the dozen different server-and-platform combinations we've specifically coded workarounds for. -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com

Re: [Web-SIG] Draft PEP: WSGI 1.1

WSGI 1.1 requires. -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/ ___ 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] CGI WSGI and Unicode

everywhere and hence used by no-one. -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/ ___ 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

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

interpretation of RFC2616 is that headers are ISO-8859-1. You will notice that no browser correctly follows this. ...sigh. -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/ -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/ ___ Web-SIG

Re: [Web-SIG] HTTP headers encoding

username handled in common WSGI frameworks? No-one supports non-ASCII characters in Authentication. Most web authors simply move to cookies instead. -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/ ___ Web-SIG mailing list Web-SIG

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

, but note that for now RFC2231-in-HTTP simply does not exist in any deployed tools. 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. -- And Clover mailto:a...@doxdesk.com http

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

-Length response header if defined. 6. The WSGI adapter must not pass on to the server any data above what the Content-Length response header defines if supplied. Yes. -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/ ___ Web-SIG mailing

Re: [Web-SIG] Future of WSGI

, which will be happy to deliver elegant Request and Response objects. -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/ ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org

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

optionally use it), but not something that can really be relied upon. -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/ ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http

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

in the response headers that cannot be encoded as Latin1? UnicodeEncodeError. Should some things be unicode on Python 2? Don't think so. -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/ -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com

Re: [Web-SIG] Getting back to WSGI grass roots.

and unicode remains firmly in the application/framework's area of concern and needs no assistance from WSGI. -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/ ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs

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

it doesn't affect QUERY_STRING parameters), but it's still not reliable, which is why today you can't have a WSGI application with pretty non-ASCII URLs that will deploy consistently. I want this fixed. -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com

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

see... -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/ ___ 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] Request for Comments on upcoming WSGI Changes

envvars using UTF-8, which won't be how Apache put them there.) If wsgi.encoding is obligatory then in reality it will often be wrong, leaving us in the same pathetic predicament as with WSGI 1.0, where non-ASCII URIs don't work reliably at all. -- And Clover mailto:a...@doxdesk.com http

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

-8 FAIL for non-UTF-8 input cherrypy.wsgiserver/Py2 use PATH_INFO directly cherrypy.wsgiserver/Py3 remains to be seen, but at the moment encode PATH_INFO to UTF-8 FAIL for non-UTF-8 input -- And Clover mailto:[EMAIL PROTECTED] http://www.doxdesk.com

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

. -- And Clover mailto:[EMAIL PROTECTED] http://www.doxdesk.com/ ___ 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 wrote: To resolve this, let's just not pass it over this time? +1 -- And Clover mailto:[EMAIL PROTECTED] http://www.doxdesk.com/ ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http

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

there on how encoding of non ascii characters works in practice. We just need to do some actual tests to see what happens and whether there is a problem. ...to which the answer is — judging by the results posted — probably “yes”, I'm afraid! -- And Clover mailto:[EMAIL PROTECTED] http

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

on it!) -- And Clover mailto:[EMAIL PROTECTED] http://www.doxdesk.com/ ___ 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] WSGI Amendments thoughts: the horror of charsets

'. -- And Clover mailto:[EMAIL PROTECTED] http://www.doxdesk.com/ ___ 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] problem with wsgiref.util.request_uri and decoded uri

]') decode_re= re.compile(r'\+([0-9a-zA-Z][0-9a-zA-Z])') def encode(s): return encode_re.sub(lambda m: '+%02X' % (ord(m.group())), s) def decode(s): decode_re.sub(lambda m: chr(int(m.group(1),16)), s) -- And Clover mailto:[EMAIL PROTECTED] http://www.doxdesk.com

Re: [Web-SIG] WSGI, Python 3 and Unicode

to be able to cope with both bytes and unicode, which would also be a big annoyance. In summary: urgh, this is all messy and 'orrible. -- And Clover mailto:[EMAIL PROTECTED] http://www.doxdesk.com/ ___ Web-SIG mailing list Web-SIG@python.org Web SIG

Re: [Web-SIG] WSGI, Python 3 and Unicode

Adam Atlas [EMAIL PROTECTED] wrote: I'd say it would be best to only accept `bytes` objects +1. HTTP is inherently byte-based. Any translation between bytes and unicode characters should be done at a higher level, by whatever web framework is living above WSGI. -- And Clover mailto:[EMAIL