W3C home > Mailing lists > Public > www-tag@w3.org > February 2004

Re: HTTP Methods

From: Roy T. Fielding <fielding@gbiv.com>
Date: Fri, 27 Feb 2004 20:54:35 -0800
Cc: <www-tag@w3.org>
To: "Thompson, Bryan B." <BRYAN.B.THOMPSON@saic.com>
Message-Id: <344C78AA-69AA-11D8-BA83-000393753936@gbiv.com>

> 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


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


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.

Received on Friday, 27 February 2004 23:54:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:03 UTC