2009/11/27 And Clover <and...@doxdesk.com>: > Ian Bicking wrote: > >> The proposal that seemed to work best was to keep the environ as str >> (i.e., >> unicode in Python 3), and eliminate the problematic SCRIPT_NAME and >> PATH_INFO, replacing them with url-encoded values. > > Ah, OK, if that's where we got to I'm happy with that - as long as the > application/framework can tell the difference between (a) old-school WSGI > 1.0 decoded PATH_INFO, (b) new verbatim PATH_INFO, and (c) a new verbatim > PATH_INFO that has been created from an old PATH_INFO by a WSGI handler > unfortunate enough to be running under CGI or IIS, potentially including > mangled characters. I would prefer to avoid the latter completely.
I was determined to stay out of this conversation, as don't particularly care anymore, but want to set the record straight. What Ian was describing was just one of a few proposals which were put up about additional changes to WSGI on top of what is already the defacto WSGI 1.X definition for Python 3.X as defined by existing practice in the form of wsgiref in Python 3.1 and mod_wsgi 3.0 (as implemented for more than a year, and recently released officially due to being fed up with waiting). One of the other major WSGI servers also is implementing that defacto WSGI 1.X definition for Python 3.X. That WSGI server hasn't as far as I know been officially released, so will leave it up to author to comment on whether they are still intending it to release it that way. Anyway, Ian's proposal just so happened to be the last one which was discussed. Just like the other proposals there were issues with it and not everyone necessarily agreed. Note that lack of response doesn't mean consent, and frankly various people were quite tired of the discussion at that point and various people whose opinions would be important to know had dropped out of the discussion. I would be even further disappointed in Python WEB-SIG if that last proposal now simply got rubber stamped purely because it was the last proposal anyone remembered, without some critical study done on whether it is even practical to implement in a reliable way across hosting mechanisms which don't have direct access to the actual processing of request headers and in particular the decoding of the original REQUEST_URI into SCRIPT_NAME and PATH_INFO. Specifically, in relation to the inability or potential difficulty in such hosting mechanisms to extract out from REQUEST_URI the original parts which mapped to the final SCRIPT_NAME and PATH_INFO. No matter what you all end up deciding to do, and whether or not start_response() is dropped, any new specification will have to be called WSGI 2.0 due to the existence of the defacto WSGI 1.X definition for Python 3.X. Graham _______________________________________________ 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
