2006/6/8, Mark Nottingham [EMAIL PROTECTED]:
On 2006/06/07, at 11:40 PM, Thomas Broyer wrote:
My main concern is that RFC3229 w/ feeds is being deployed more and
more widely and is still not even an I-D (or I missed something).
I have that concern as well.
I am also concerned that RFC3229 is an extension of HTTP, but some
implementers are acting as if it chages the semantics of already-
defined parts of HTTP. For example, a delta must be a subset of the
current representation that is returned to a GET; if you GET the
feed, it has to return all of the entries that you could retrieve by
using delta.
I have a feeling that many people are treating it as a dynamic query
mechanism that's capable of retrieving any entry that's ever been in
the feed, while still only returning the last n entries to a plain
GET. If so, they're breaking HTTP, breaking delta, and should use
something else.
Is this the case, or am I (happily) mistaken?
RFC3229 adds a new notion, the one of instance and defines that the
ETag is computed based on the instance, not the entity (difference
between instance and entity being the instance-manipulation –delta,
diff, or identity, which is the default in bare HTTP– having been
applied).
Now, let's define the feed resource as the complete set of entries,
and its default representation as one which shows only the most recent
ones (using a yet-to-be-defined conneg algorithm –e.g. using an
Accept-Features feature–, it could be possible to retrieve the whole
set of entries).
If I'm wront in the above statement (conneg could lead to a latest
entries only or full, without abusing HTTP), then don't even read
further, this would mean that RFC3229 w/ feed changes the semantics of
existing parts of HTTP.
Let's take the steps in section 4 of RFC3229:
Conceptually, the various transformations are applied in the
following sequence:
1. Upon receiving a GET request, the server uses the URI in the
request to identify the requested resource.
2. Optionally, it uses information from the request (and perhaps
additional information) to select a variant of that resource.
The server might here use the presence of the A-IM request header to
select the full representation of the feed rather than the latest
entries only representations.
3. At this point, the server may apply a non-identity content-
coding to the instance, or one might have been inherent in its
generation. This also results in a Content-Encoding header.
4. The result of the first three steps, at the time when the
request is processed, is an instance. The instance includes a
body (possibly empty) and possibly some instance headers. The
entity tag, if any, is assigned at this point. That is, an
entity tag is associated with an instance, NOT an entity.
If I read RFC2616 correctly, nothing prevents the latest entries
only and full representations (or any representation of the same
resource) to share the same entity-tag, i.e. nothing prevents a server
to assign an entity-tag to a resource rather than its representations.
Maybe servers should use a weak etag in this case? But RFC2616 says in
section 13.3.3 that Clients MAY issue simple (non-subrange) GET
requests with either weak validators or strong validators. Clients
MUST NOT use weak validators in other forms of request.
5. The server may then apply an instance-manipulation. For
example, if the request included a Range header, the server may
optionally produce a range response, consisting of the original
set of headers, a Content-Range header, and the appropriate
range(s) from the (possibly encoded) body. Delta encodings are
instance-manipulations, and are computed at this stage.
Given the ETag of the previous version of the feed, the server can
compute the delta and make it a feed of added and updated entries.
6. The result of the fifth step becomes the entity, consisting of
entity headers and an entity body.
7. The server may then apply a non-identity transfer-coding; on-
the-fly compression could be done in this step. If so, a
Transfer-Encoding header is added to the message.
8. The results of the seventh step is the message, consisting of a
message body (the transfer-coded version of the entity body),
the entity headers, and additional response and general
headers.
--
Thomas Broyer
