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

Re: bug, or "feature"?

From: James Casey <jamesc@harlequin.co.uk>
Date: Tue, 2 Jan 1996 20:08:30 +0000
Message-Id: <v02130507ad0f2cf9b1bb@[]>
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.

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.

Received on Tuesday, 2 January 1996 15:11:52 UTC

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