- From: Shel Kaphan <sjk@amazon.com>
- Date: Tue, 2 Jan 1996 10:24:26 -0800
- 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 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
Received on Tuesday, 2 January 1996 13:28:20 UTC