Ian Bicking wrote: > But relating REQUEST_URI with SCRIPT_NAME/PATH_INFO is awkward and > having the information in duplicate places can lead to errors and > unclear situations if they don't match up properly.
True, and you can apply the same reasoning to my suggestion too. Apart from the duplication of information, there's how or where to do the actual decoding. Not everyone is dispatching to a CherryPy-style tree of objects, so putting a %-decoded list of path segments in a environ key doesn't work -- I knew it was a bad idea! I'm going with CherryPy's on this: don't decode "%2F". Should other characters be kept encoded? Also, this crystallizes my thoughts on the matter: %-decoding is the applications' job. Or frameworks'. *Not* the servers'. > Luis Bruno wrote: >> I was not amused to see egg:Paste#http urldecoding the whole PATH_INFO. > Unfortunately this is in the WSGI spec, so it's not Paste#http so much > as WSGI that demands this. Cite? I skimmed PEP 333 before grumbling and I've just re-read it; didn't find it, unless you're referring to the code in "URL Reconstruction" section. If you're referring[*] to the CGI 1.1 draft linked in "environ Variables", I think it supports my position that unquoting(PATH_INFO) was not the correct thing to do. [*] I'm not sure how to spell that. > I made note of this issue on the WSGI 2.0 ideas page Didn't find it here: <URL:http://wsgi.org/wsgi/WSGI_2.0>. Should I look elsewhere? > [/Laptops/LN500%2F9DW/ ] would be the Right Thing, except for not > being WSGI. Looks to me like a good candidate for an amendment. What's the next step? -- Luís Bruno _______________________________________________ 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