Re: bug, or "feature"?

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