W3C home > Mailing lists > Public > uri@w3.org > May 2002

Re: comments on RFC 2396 relative URL examples

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Fri, 17 May 2002 10:01:13 +0200
Cc: <uri@w3.org>
To: <LMM@acm.org>
Message-Id: <41C2FDCB-696C-11D6-84D2-00039384827E@greenbytes.de>

Am Freitag den, 17. Mai 2002, um 07:44, schrieb Larry Masinter:

> The example of resolving a relative URL could be improved.  It uses a
> base
> of http://a/b/c/d;p?q
> Not wanting to read the RFC end to end, it took me a bit of 
> searching to
> find that the ;p part is a "parameter" and the ?q part is a "query".
> But I
> have no idea what their relevance is to this example.  It they are 
> to be
> ignored when attaching the relative parts, it would be nice to say so.

I read it like this:
- query parts in base uris are to be ignored
- parameters belong to a path segment and are ignored
   iff the path segment is ignored

> The basic expansion has one very confusing and not explained aspect.
> The
> relative path g is said to expand to http://a/b/c/g instead of
> http://a/b/c/d/g.  The other expansions are obvious once the "remove d"
> rule
> is applied.  Would a base of http://a/b/c/d/ plus g expand to
> http://a/b/c/d/g?


> The examples should have enough annotation to
> mostly stand on their own and to reinforce the concepts.

I found them to be very helpful in their current form. The
only thing I would state differently is the handling of
too many ../ in the resolved uri.

The RFC currently states that

base http://host/a/b
ref  ../../c
resolves to http://host/../c

and continues that removing the /.. at the beginning is allowed.

My observation is that removing /.. is the norm nowadays
and therefore the example should be the other way with a
note that keeping /.. is allowed.

Received on Friday, 17 May 2002 04:01:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:04 UTC