On Fri, Sep 18, 2009 at 11:21 AM, Graham Dumpleton <graham.dumple...@gmail.com> wrote: > 2009/9/18 Benoit Chesneau <beno...@couch.it>: >> And sometimes you need to support full uri spec. For example %2F is >> different from / . Actually if all url is decoded you don't know if the >> client request was %2F or /, you just get a /. Which is annoying. It causes >> some problem with some api ,I'm thinking to couchdb for example who accept >> db name with a %2F inside to allow creation of folder on user system. > > Which happens because of the way the HTTP URL processing rules says it > has to be done. > > Are there any other real world examples besides repeating slashes and > slash encoding issues? > > Is the desire to bypass traditional SCRIPT_NAME and PATH_INFO and go > direct to REQUEST_URI all come down to these slash encoding and path > normalising issues? >
hello again, No, slash encoding and normalising are not the only issues. As mentioned before sometimes you need the exact bytes. 1. buggy clients. If a client sends something that doesn't work correctly, you can still sometimes make sense of it in the raw version of the url. 2. client APIs that require the server to know the exact url. 3. buggy servers that don't do their job properly. 4. extensibility. A url scheme changes a tiny bit, and you want to support the change. Having the raw url allows you do to support it on old servers. In all APIs it's handy to go to lower levels when the higher levels don't work right. Especially when wsgi only handles one side of things, and urls are can be generated by anything. cheers, _______________________________________________ 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
