Re: URL-Reference / "empty URL" question

"Roy T. Fielding" <> Wed, 14 May 1997 19:41 UTC

Received: from cnri by id aa05059; 14 May 97 15:41 EDT
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa15681; 14 May 97 15:41 EDT
Received: (from daemon@localhost) by (8.8.5/8.8.5) id PAA08693 for uri-out; Wed, 14 May 1997 15:12:39 -0400 (EDT)
Received: from (mocha.Bunyip.Com []) by (8.8.5/8.8.5) with ESMTP id PAA08687 for <>; Wed, 14 May 1997 15:12:36 -0400 (EDT)
Received: from ( []) by (8.8.5/8.8.5) with SMTP id PAA06677 for <>; Wed, 14 May 1997 15:12:30 -0400 (EDT)
Received: from by id aa05129; 14 May 97 12:01 PDT
To: Foteos Macrides <>
Subject: Re: URL-Reference / "empty URL" question
In-reply-to: Your message of "Wed, 14 May 1997 11:07:01 CDT." <01IIUUP7CVEE00A3D1@SCI.WFBR.EDU>
Date: Wed, 14 May 1997 11:56:20 -0700
From: "Roy T. Fielding" <>
Message-ID: <>
Precedence: bulk

In addition to Larry's comments, I think it is important to keep in
mind that just because the spec says

     UA should not do action for empty URL

it does not imply that

     UA should do action for non-empty URL

In particular, whether or not a UA performs a retrieval of a URL
which is identical to that of the current document should depend
on the context of the request and not on any requirement in the spec
(at least none that I can remember at the moment).

>	That rule to resolve versus (current document) rather than the
>base makes good sense in this case, as well as homologous cases in
>which the position indicated by the "lone fragment" applies to the
>currently displayed document (and most likely also in the document
>pointed to by the base, by why get it again simply to change the
>"view" rather than the actual document), so I hope this rule will we
>adopted by all browers.

Right, that is the intended result.

>	In the case for which the current document is retrieved via an
>http URL, there is no file://localhost/... formally associated with it.
>The browser may or may not be maintaining a local cache, and if it is,
>the local copies would be associated with references based on its cache
>access rules in relation to http://host/foo/blah/original.html.  You
>would still want to resolve "lone fragments" versus that (current
>document) URL, but if there is no BASE nor http header or META
>equivalent indicating a different base, you could get the same thing
>if a path also were in the partial reference, or if it where an
>absolute URL with the fragment appended. 
>	Klaus' interpretation (and Larry's seeming affirmation of it)
>amounts to the rule that the "lone fragment" should be resolved as:
>	(cache reference)#top
>not just:
>	(current document)#top
>and Klaus has added code to keep track of how each reference with a
>fragment was resolved, i.e., whether or not if was a "lone fragment"
>in the HTML markup, and if so always use that information to bypass any
>associated cache directives, rather than bypassing them on the basis
>of whether the actual URL (without a fragment) corresponds to that of
>the currently displayed document.  I find it very difficult to believe
>that Roy intended to take it that far, and doubt that any currently
>deployed browser has (aside from the Lynx working code to which Klaus

Yep, this is the part that I think should depend on the context of the
request and the configuration of the browser.  I didn't say anything
about this in the spec because the only interoperability problem is
the case where BASE differs from the retrieved URL.