On Sat, Jul 17, 2010 at 12:38 AM, Graham Dumpleton < graham.dumple...@gmail.com> wrote:
> 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 filenames, > > FWIW, I had to go to a lot of trouble to allow non ASCII in final > SCRIPT_NAME in mod_wsgi. Specifically using AddHandler directive in > Apache means a file system path can make up part of SCRIPT_NAME. I had > someone who was specifically using Russian in a WSGI script file name > and because with AddHandler that becomes part of SCRIPT_NAME you had > to cater for it. Anyway this was more of a Windows issue in having to > use special file system functions to deal with fact that on Windows > filesystem paths aren't UTF-8 but something else. > > What this does highlight though is that although one can talk about > passing raw script name through to application, that isn't necessarily > right as it isn't the application that dictates what encoding may be > used but the web server which is performing the mapping of that part > of the original URL path to a potential filesystem resource, or > alternatively where file based configuration for mount point, the > encoding of the web sever configuration file. > This is an Apache-specific issue. It definitely doesn't apply to paste.httpserver, I doubt CherryPy or wsgiref. I don't really know how Nginx or other servers work. -- Ian Bicking | 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