RE: fragment prose proposal

A problem with this particular part of the rewording is that while
it is true that retaining the fragid may impact processing of some
HTTP requests by some implementations, there are other HTTP
requests for which the fragid should *not* be stripped off.

I think it would be much better to distinguish the relevance 
(or lack thereof) of fragids per each HTTP method.

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.

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.

Presuming that the server will never need to know the fragid
will preclude alot of potential solutions.

Finally, this particular RFC is probably not the place to discuss
whether a fragid is or is not stripped off before utilizing a URI
in any kind of request, other than perhaps to mention that 
such things may be done and reference the relevant specs,
etc.

I would, though, like to see the revised RFC reflect the
"sanctity" of the URI and suggest that, unless absolutely
necessary for some particular application or operation, the
URI be kept intact (with fragid if present) througout all processing.


Cheers,

Patrick


-----Original Message-----
From:	uri-request@w3.org on behalf of ext Al Gilman
Sent:	Wed 2004-02-25 16:48
To:	uri@w3.org
Cc:	
Subject:	fragment prose proposal


<to>
3.5  Fragment

    ...

    For some retrieval mechanisms such as the HTTP protocol, the User Agent
    should generally strip the #fragment and apply it locally, as some
    server implementations may not process the URI correctly with
    the #fragment component retained.

</to>

Received on Thursday, 26 February 2004 00:45:36 UTC