Re: URL-Reference / "empty URL" question

["Roy T. Fielding" <[e-mail]>]

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
>alluded).

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.

.....Roy