- From: James Casey <jamesc@harlequin.co.uk>
- Date: Tue, 2 Jan 1996 20:08:30 +0000
- To: Mike Dilworth <mjd@soi.city.ac.uk>, www-talk@w3.org
At 13:20 2/1/96, Mike Dilworth wrote: >>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. >> >>Do people think this is >>a) a bug >>b) a feature >>c) none of the above ? > >if its not a bug, then its a pretty crappy feature, which I for one would >like to see removed !! Unfortunately, I see it as a feature that can't be removed currently. Currently, 1) Client sends absolute-URI to server (no frag-id) 2) Server sends back 302 Redirect along with new URI ( possibly with a #Frag-id) 3) Client fetches new absolute-URI, and points into appropriate frag-id in new URI. Since the server never knows that there was a frag-id in the original request, it can't add it to the redirect URI. I see no simple solution, apart from a client side heuristic to place focus at the old frag-id if none is returned in the redirect URI, but this does not seem clean. It does highlight a general problem in the handling of fragment identifiers as they are currently used; since the server never sees them, it cannot do anything useful with them. This has come up in creating dynamic documents where content is gernated at access time -- there is no general mechanism for passing back fragment identifiers, so hacks have to be created to get around this. Perhaps this is the time to implement some way of passing back presentation side specializers, separate from the URI. james.
Received on Tuesday, 2 January 1996 15:11:52 UTC