[9529] in www-talk@info.cern.ch
Re: bug, or "feature"?
daemon@ATHENA.MIT.EDU (Shel Kaphan)
Tue Jan 2 13:41:17 1996
Date: Tue, 2 Jan 1996 10:24:26 -0800
From: Shel Kaphan <sjk@amazon.com>
To: "Daniel W. Connolly" <connolly@beach.w3.org>
Cc: Larry Masinter <masinter@parc.xerox.com>, sjk@amazon.com, www-talk@w3.org
In-Reply-To: <m0tWpjU-0002UgC@beach.w3.org>
Resent-From: www-talk@w3.org
Daniel W. Connolly writes:
> In message <95Dec29.204102pst.2733@golden.parc.xerox.com>, Larry Masinter write
> s:
[ I write: ]
> >> I've just discovered that with some popular browsers, including the
> >> latest from Netscape, if you do a GET on a URL with a fragment (an
> >> anchor, a "#something" on the end), and the server issues a redirect
> >> (302) so that a different document is fetched, then the browser will
> >> NOT seek to the anchor to the ultimately viewed document -- you end up
> >> staring at the beginning of the page.
> >
> >I think it's a bug. I suppose this should be clarified in the next
> >revision of the URL documents.
>
> 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:
...
> Dan
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?
--Shel
