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

ody that is always bytestring. > * Should the returned iterable be rejected 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, --

Re: [Web-SIG] urllib.unquote in paste.httpserver prevents slashes in path segments

are stuck with it for the foreseeable. -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com gtalk:chat?jid=bobi...@gmail.com ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/m

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

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] wsgiref 0.2 dev in svn w/PEP 3333 support

NFO. This is a bit more risky as existing apps/libraries may already be doing this and might get confused if someone's already done the fix. Maybe a subclass like IISCGIHandler? -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/ ___

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

ript because an error happens and spits 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

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

. Probably not a good idea for an application to require this, but it's here for completeness. -- 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 Uns

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

s is the only component it is reasonable to burden 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 i

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

r an ErrorDocument. Cookie is also the one header that can't be safely folded. 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/ ___

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

work on the web, due to poor server/UA compatibility and the existence of long, inherently non-foldable headers (eg. try passing a Authorization header containing a Kerberos ticket in 80 columns). -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/ ___

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

rruptions lurk inside PATH_INFO and apps 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 Clove

Re: [Web-SIG] WSGI for Python 3

code paths when run on a server/gateway that supports ", 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...@doxd

Re: [Web-SIG] WSGI for Python 3

uch as REQUEST_URI or Windows 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:

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

part. quote() defaults to UTF-8 rather than the ISO-8859-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] IIS and Python CGI - how do I see more than just the form data?

that can't reliably be used in a path part, including slashes, backslashes, control characters, and all non-ASCII characters (since they go through a Unicode decode/encode cycle with what are almost guaranteed to be the wrong charsets). Stick with simple strings like `someuser`.

Re: [Web-SIG] CGI WSGI and Unicode

cookies are already totally broken 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

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

should interact with HTTP, 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 mai

Re: [Web-SIG] HTTP headers encoding

ur has not changed. > This is really a mess. Isn't it. > How is authorization 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/

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

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. ...sigh. -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/ -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/

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

refuse to run on 1.0 if it requires these behaviours? >> 5. Any WSGI application or middleware should not return more data than specified by the Content-Length response header if defined. >> 6. The WSGI adapter must not pass on to the server any data above what the Content-Length re

Re: [Web-SIG] Future of WSGI

who want pretty can use frameworks, 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 U

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

l as a fixup possibility (several of my apps 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://w

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

response bodies between bytes 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

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

you give unicode text 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...@doxd

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

sequences (such as overlongs) through filters, potentially causing endless security problems. But we'll 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

be as troublesome as it is in Java (mainly because for us 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

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

use ad-hoc encoding methods. As Cookie is an actual HTTP header the encoding should presumably be ISO-8859-1, but I don't think it actually works anywhere. -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/ -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/ _

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

ers. Python 3 has the opposite problem reading byte 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 relia

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

recover non-ASCII characters from PATH_INFO/QUERY_STRING, with undefined results. This is the broken-but-sometimes-rescuable status quo for CGI: by the time Python reads non-ASCII characters out of the environment they may already have been mangled by up to two conversion processes. --