Re: URL-Reference / "empty URL" question

Foteos Macrides <MACRIDES@sci.wfbr.edu> Wed, 14 May 1997 20:39 UTC

Received: from cnri by ietf.org id aa07540; 14 May 97 16:39 EDT
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa16722; 14 May 97 16:39 EDT
Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id QAA11082 for uri-out; Wed, 14 May 1997 16:21:43 -0400 (EDT)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id QAA11077 for <uri@services.bunyip.com>; Wed, 14 May 1997 16:21:40 -0400 (EDT)
Received: from sci.wfbr.edu (sci.wfbr.edu [192.190.14.2]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id QAA07407 for <uri@bunyip.com>; Wed, 14 May 1997 16:21:36 -0400 (EDT)
Received: from SCI.WFBR.EDU by SCI.WFBR.EDU (PMDF V5.0-4 #19169) id <01IIV6OXHXI800A3D1@SCI.WFBR.EDU>; Wed, 14 May 1997 16:20:43 -0500 (EST)
Date: Wed, 14 May 1997 16:20:43 -0500
From: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Subject: Re: URL-Reference / "empty URL" question
To: liberte@ncsa.uiuc.edu
Cc: uri@bunyip.com
Message-id: <01IIV6OXI5ZM00A3D1@SCI.WFBR.EDU>
X-VMS-To: IN%"liberte@ncsa.uiuc.edu"
X-VMS-Cc: IN%"uri@bunyip.com",MACRIDES
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-uri@bunyip.com
Precedence: bulk

Daniel LaLiberte <liberte@ncsa.uiuc.edu> wrote:
> > On Wed, 14 May 1997, Larry Masinter wrote:
> > 
> > >   "the copy of the content that is being viewed now"
> > > 
> > > Let's give it its own URL scheme
> > >    "this:"
> > > where the scheme-specific part of "this:" is
> > > empty.
>
>Doesnt the empty URL "" work just as well?  Experience shows that
>if you have an anchor such as <A HREF="">this document</A> it goes
>to the same document that it is contained in.
>
> > I'm not sure, but I seem to detect in some of the comments
> > in this thread a question as to why there could be a need
> > to move inside a document without every refetching it (from
> > the cache or wherever).
>
>Moving within a document without refetching it is an orthogonal issue,
>I think.  It is closely related to the browsing history issue.

	Yes, that's the point.  HREF="" resolves to the current
document's actual URL (without a fragment, if one was present in
the link via which the request yielding the current document was
made)  HREF="#fragment" is HREF="" + HREF="#fragment" yielding an
absolute URL with the current document's actual URL, not the base
(which may be different), plus the #fragment "instruction" to the
client (not to be included in any request sent to a server, or
conversion to file system specs for retrieval from disk.

	However, most deployed browsers resolve HREF="#fragment"
versus the base.  That needs to be changed.  In most cases the
absolute URL from resolving versus the base also points to a document
with the NAME-ed reference pointed to by the #fragment, so there's
little "backward compatibilty" to worry about if the new URL draft
pushes for this implementation.  The freeware Mosaic and Lynx v2.7
have implemented it, so the "at least two implementations" requirement
is met as well.

	But there's no need to introduce a "this:" or "goldalhistory:"
internal URL concept into this:

	The equivalent of that it has existed since the outset of the
Web via the procedure of comparing the actual URL (without the fragment)
to that of the currently displayed document.  When FORMs came into being,
a comparison of any POST content was made as well.  If, by those checks,
the resolved reference proves to be the currently displayed document,
then the browser simply changes the view as indicated by the fragment
reference, without making another request, or considering any cache
control directives associated with the document:  It's dealing with
"history", not "cache" by virtue of that comparison.

	But the same should apply no matter how the "URL#fragment"
was resolved.  If the URL (plus any POST content) corresponds to
that of the currently displayed document, it's a history/view, not
cache control issue.

	Moreover, if there is POST content and they differ, then
whether or not the resolving was done based on an HREF="#fragment",
they are different on those grounds, and cache control, not just
history/view considerations do apply.

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================