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: HRB5782Received on Wednesday, 1 August 2007 07:27:22 UTC
This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:49 UTC