[9533] in www-talk@info.cern.ch
Re: bug, or "feature"?
daemon@ATHENA.MIT.EDU (Daniel W. Connolly)
Tue Jan 2 16:05:09 1996
To: Shel Kaphan <sjk@amazon.com>
Cc: Larry Masinter <masinter@parc.xerox.com>, www-talk@w3.org
In-Reply-To: Your message of "Tue, 02 Jan 1996 10:24:26 PST."
<199601021824.KAA07765@bert.amazon.com>
Date: Tue, 02 Jan 1996 15:56:57 -0500
From: "Daniel W. Connolly" <connolly@beach.w3.org>
Resent-From: www-talk@w3.org
In message <199601021824.KAA07765@bert.amazon.com>, Shel Kaphan writes:
>Daniel W. Connolly writes:
> > I agree that it's not the way I'd like it to work. However, according
> > RFC1808, it's quite clearly a feature:
> >
> > http://www.w3.org/pub/WWW/Addressing/rfc1808.txt
> >
> > 5. Examples and Recommended Practice
> >
> > Within an object with a well-defined base URL of
> >
> > Base: <URL:http://a/b/c/d;p?q#f>
> >
> > the relative URLs would be resolved as follows:
>
> ...
>
>Sorry if I'm being dense, but I'm not exactly sure what the
>relationship is between resolving relative URLs and using (or losing)
>a fragment after a redirection. If you issue a request on request on URL
> bla1#fragment
>and get redirected to bla2, then the desired
>behavior after the client fetches and receives bla2 is to use
>"#fragment" to seek into the document. Since #fragments are not part
>of the URL sent in either the first or second request to the server,
>where does resolution of relative URLs come into it?
Hmmm... good point. I guess I was out in left field.
You're right:
Defn: go(U#F) = view(get(U), F)
If: get(U) = get(U') (redirection)
--------------------------
Then: go(U#F) = view(get(U'), F)
Dan
