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

Re: bug, or "feature"?

From: Daniel W. Connolly <connolly@beach.w3.org>
Date: Tue, 02 Jan 1996 15:56:57 -0500
Message-Id: <m0tXDlR-0002T1C@beach.w3.org>
To: Shel Kaphan <sjk@amazon.com>
Cc: Larry Masinter <masinter@parc.xerox.com>, www-talk@w3.org
In message <199601021824.KAA07765@bert.amazon.com>, Shel Kaphan writes:
>Daniel W. Connolly writes:
> > 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:
>	...
>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?

Hmmm... good point. I guess I was out in left field.

You're right:

Defn:	go(U#F) = view(get(U), F)

If:	get(U) = get(U')	(redirection)
Then:	go(U#F) = view(get(U'), F)

Received on Tuesday, 2 January 1996 15:57:50 UTC

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