Re: URL-Reference / "empty URL" question

Klaus Weide <kweide@tezcat.com> Wed, 14 May 1997 23:15 UTC

Received: from cnri by ietf.org id aa11825; 14 May 97 19:15 EDT
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa19595; 14 May 97 19:15 EDT
Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id SAA16273 for uri-out; Wed, 14 May 1997 18:48:06 -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 SAA16267 for <uri@services.bunyip.com>; Wed, 14 May 1997 18:48:02 -0400 (EDT)
Received: from huitzilo.tezcat.com (kweide@huitzilo.tezcat.com [204.128.247.17]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id SAA09255 for <uri@Bunyip.Com>; Wed, 14 May 1997 18:47:59 -0400 (EDT)
Received: from localhost (kweide@localhost) by huitzilo.tezcat.com (8.8.5/8.8.5/tezcat-96091001) with SMTP id RAA24671; Wed, 14 May 1997 17:47:51 -0500 (CDT)
Date: Wed, 14 May 1997 17:47:51 -0500 (CDT)
From: Klaus Weide <kweide@tezcat.com>
Reply-To: Klaus Weide <kweide@tezcat.com>
To: Foteos Macrides <MACRIDES@sci.wfbr.edu>
cc: uri@bunyip.com
Subject: Re: URL-Reference / "empty URL" question
In-Reply-To: <01IIV6OXI5ZM00A3D1@SCI.WFBR.EDU>
Message-ID: <Pine.SUN.3.95.970514171241.19055F-100000@huitzilo.tezcat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-uri@bunyip.com
Precedence: bulk

On Wed, 14 May 1997, Foteos Macrides wrote:

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

Has it not also caused problems since the outset of the Web?
(Just a question.  I haven't been around.)

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

That sounds like a bug, not a feature.

In many cases a FORM's ACTION= URL doubles as the URL of the page which
contains the form (which might contain introductory explanations or
instructions not included with every response of a submission, etc). 
With METHOD=POST, this means the text/html document returned as a result
of a submission cannot contain <A HREF="http://our.server/this-URL">...</A>
or <A HREF="this-URL#intro">..</A> links - they would be misinterpreted as
a request for re-submitting the form and/or repositioning within the
submission response.

> 	But the same should apply no matter how the "URL#fragment"
> was resolved.  

I see no reason why this limitation should be lifted to the rank of a
"should"...

> If the URL (plus any POST content) corresponds to
> that of the currently displayed document, it's a history/view, not
> cache control issue.

You are describing how this has historically been handled, and the weight
of that history may well prevent any changes.  That doesn't mean that this
behavior is desirable, or deserves to be encouraged in other clients...


   Klaus