- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Wed, 1 Aug 2007 09:26:59 +0200
- To: Mike Schinkel <mikeschinkel@gmail.com>
- Cc: <uri@w3.org>
Am 31.07.2007 um 21:30 schrieb Mike Schinkel: > Stefan Eissing wrote: >> converter MUST perform path resolution as described in RFC >> 3986 ch. 5.2.3 and 5.2.4. That will also stop some injections >> of "." and ".." into URIs while saving the client from >> worrying to much about double "/" and such. > > I read the spec but am one that still has trouble understanding > portions of > a spec that do not include examples such as those. Which of the > following > are you saying it should result in? > > A.) http://www.example.com/ > B.) http://www.example.com// Clearly A. The path resolution will always make conversions such as: // -> / /./ -> / /a/../b -> /b > usable. Imagine the following where most of the time all parameters > would be > null: > > http://www.example.com/?a={a}&b={b}&c={c}&d={d}&e={e}&f={f}&g={g} > > Without optional parameters the URLs almost always look like this > (<ugh>): > > http://www.example.com/?a=&b=&c=&d=&e=&f=&g= > > Instead of, more approripately, like this (<smile>): > > http://www.example.com/ > http://www.example.com/?a=foo > http://www.example.com/?c=bar > http://www.example.com/?d=foo&f=bar Clearly, such urls are better than the one with all empty params. Perhaps this can be solved outside the spec. Your example: http://www.example.com/?a={a}&b={b}&c={c}&d={d}&e={e}&f={f}&g={g} could also be transformed to the template http://www.example.com/?{params} The task to make usage elegant to an application could then be in the uri template resolver code. If you pass a hash/dictionary/map as value for "params", the resolver could build the query parameter itself. -- Stefan Eissing <green/>bytes GmbH Hafenweg 16 D-48155 Münster Germany Amtsgericht Münster: HRB5782
Received on Wednesday, 1 August 2007 07:27:22 UTC