- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Fri, 27 Feb 2004 20:54:35 -0800
- To: "Thompson, Bryan B." <BRYAN.B.THOMPSON@saic.com>
- Cc: <www-tag@w3.org>
> Any comment on combining the use of the XPointer Framework with the
> HTTP "Range" request header? A server that understands the "xpointer"
> range-unit would process the XPointer expression (in the Range header)
> and send back the addressed sub-resources as a multipart MIME type.
Umm, yuck! But at least that is compliant with HTTP. Range is
very hard to do right, and almost always breaks across proxies.
Generally speaking, it should only be used for byte ranges, and only
then for the sake of finishing incomplete downloads or working around
limited client buffers.
> The use of the HTTP "Range:" request header seems to be the key to
> having the server process the XPointer expression since, as you
> point out, the fragment identifier is not even transmitted in the
> HTTP request.
>
> [1] http://wiki.cognitiveweb.org/XPointerAndHttpRange (rough draft)
I can't access that directly, but if I go to
http://cweb.sourceforge.net/cgi-bin/moin.cgi/HttpRangeAndXPointer
it redirects to the right content. *shrug*
A better solution is to let the server define its own URI space
such that it gives the client a license to dig deeper. E.g., a
link header field like
Link: <http://example.com/big/resource;xpf=>; rel="xpointable"
tells the client the URI
http://example.com/big/resource;xpf=xpath(//item/3)
can be constructed to identify the resource that is described
by that xpath. However, personally, I would avoid use of anything
other than id's, since manipulation of the XML data tree will
create an implementation dependency between client and server.
....Roy
Received on Friday, 27 February 2004 23:54:47 UTC