Re: URL-Reference / "empty URL" question

On Wed, 14 May 1997, Roy T. Fielding wrote:

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

There is an additional twist here.  We (Fote and I) seem to agree that in

>>  <A NAME=link-1" HREF="http://a.host/a.file.html"    >link one   </A>
>>  <A NAME=link-2" HREF="http://a.host/a.file.html#top">link two   </A>
>>  <A NAME=link-3" HREF="#top"                         >link three </A>
(appearing in a document retrieved from http://a.host/a.file.html)

following link-1 should do a new retrieval (for example if there is a
no-cache in effect).  This seems to be what some page authors expect, but
may fall under configuration of the browser.

Given this behavior for link-1, can it then be legitimate to treat link-2
totally different?  Presence or absense of a fragment then decides on
whether a retrieval is done, it seems to contradict everything I know
about fragments.  The "context of the request" is the same in all cases: a
user following a hyperlink given by A HREF.

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

It gets messy, but seemed to be the only logical consequence of
 1) the draft's "lone fragment rule"           (link-3, above)
 2) the given decision how to handle activation of a link - "forward", 
    not by history list -  for everything else (including link-1)
 3) a rule (only imagined??) that presence or absense of a fragment
    cannot have any other effect but positioning, for text/html documents.

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

Interoperability problems about controlling when a client should
intitiate a new request seem to be an important motivation for the
http-wg's uahint draft (just problems of a different kind).  I guess
that draft should say something about fragments, currently it doesn't
mention them at all.

Without the interpretation I made, there is no way to let a simple
hyperlink have the effect "retrieve new copy of this resource, then
goto #chapter3".  Well, currently it seems there isn't a well-defined
and uniformly implemented behavior for *any* of the three cases on
which an author could rely, so no big loss...  it just seems that
leaving less to "configuration of the browser" would be desirable.
(Especially when it's not configurable but an arbitrary implementation
choice.)  

All this may not belong in an url-syntax document.  A statement that
presence or absense of a fragment cannot change what the URL in the
URL-Reference refers to, *nor how it is meant to be accesses*, might
belong.  If the authors feel it makes sense, and if there is any chance
this will have any practical effect...

   Klaus

Received on Wednesday, 14 May 1997 18:05:08 UTC