W3C home > Mailing lists > Public > www-talk@w3.org > January to February 1996

Re: bug, or "feature"?

From: Shel Kaphan <sjk@amazon.com>
Date: Tue, 2 Jan 1996 10:24:26 -0800
Message-Id: <199601021824.KAA07765@bert.amazon.com>
To: "Daniel W. Connolly" <connolly@beach.w3.org>
Cc: Larry Masinter <masinter@parc.xerox.com>, sjk@amazon.com, 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
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?

Received on Tuesday, 2 January 1996 13:28:20 UTC

This archive was generated by hypermail 2.4.0 : Monday, 20 January 2020 16:08:19 UTC