[Web-SIG] String Types in WSGI [Graham's WSGI for py3]

[René Dudfield]

On Fri, Sep 18, 2009 at 11:21 AM, Graham Dumpleton
<graham.dumpleton at gmail.com> wrote:
> 2009/9/18 Benoit Chesneau <benoitc at 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,