Re: fragment prose proposal

Patrick.Stickler@nokia.com wrote:

> there are other HTTP requests for which the fragid should *not* be
> stripped off.

Are you sure?  I bet some people would find that view heretical.  :)

> Ideally, the fragid would never be stripped off of any request and the
> server would be free to decide whether it is relevant to the request
> or not.

I think that would simply turn the fragment-id into another
query-string.  We already have a query-string with a very general
syntax; we don't need another.  If the fragment-id is ideally
interpreted by the server, then the client ideally needs to contact
the server even to follow a relative reference like "#foo".  This
would defeat the original purpose of the fragment part of the
URI, and therefore it would need to be reinvented as another
client-side-and-this-time-we-really-mean-it URI suffix.

> There have been cases where I would have wanted to have recieved the
> fragid in a GET request so that I could choose, based on other header
> parameters, whether to provide an XML Fragment of a representation,
> corresponding to the secondary resource rather than the entire
> representation.

But after the client fetches http://server/path#foo, if it then follows
a link to #bar, will it know that it needs to contact the server again
and ask for http://server/path#bar, or will it assume that it already
has all of http://server/path and therefore if it doesn't find #bar
within it, it's a dangling link?

If you want it interpreted by the server, why not just put it in the
query-string?

Whatever else might be said about fragment-ids, I think at the very
least we should stick with the following core principle, articulated by
Larry Masinter:

> I think that the important bit is that the fragment identifier is not
> used in the scheme-specific processing of the URI.

AMC
http://www.nicemice.net/amc/

Received on Friday, 27 February 2004 03:11:54 UTC