W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2007

RE: thinking about etags

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Mon, 27 Aug 2007 11:15:42 +0200
To: Larry Masinter <LMM@acm.org>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1188206142.15667.42.camel@henriknordstrom.net>
On sön, 2007-08-26 at 14:12 -0700, Larry Masinter wrote:

> I suppose you're right. Mainly, though, the point is that the eTag
> corresponds to the entity and not to the resource;

Yes. But the distinction between resource and entity is a bit muddled,
and are often used interchangeably, which works fine for GET requests on
non-varying resources but not otherwise.

my understanding:

An entity is the HTTP representation of a resource or it's result.

A resouce is a server-side representation or data processor, preferably
identified by a unique URI.

ETag ends up somewhere between the two.. but yes, it's more related to
the HTTP entity than the resource.

Probably the main source to the confusion is that HTTP servers have
evolved and today often work in manners which wasn't really considered
when the RFC was written, adding a lot more dynamics to the process. And
additionally the HTTP object and cache model is not well understood by
most which makes it hard for them to correctly place the ETag relation.

I still often find people who insists that the ETag for two response
entities from the same resource, differing only in the content-encoding
should be the same, as they are generated from the same resource and
both represents the same..

> I guess it was in the discussion about PATCH where people were getting
> confused. I thought it was interesting that ICAP defined "ISTag"
> just to have a way of talking about resource state rather than
> entity state.

Well.. ICAP doesn't really have resources in the same sense as HTTP, and
ETag would not fit. It's cache model is very different with the cache
being defined by the encapsulated protocol rather than ICAP itself..

The equalence in HTTP would be caching of a protocol carried over HTTP
POST requests or similar, where the request-URI only identifies the
processing resource. (i.e. XMLRPC). And there ISTag would be a good fit.
Additionally ISTag is not a validator, just an informational response

I suppose it could fit for WEBDAV as well, but don't understand the
fineprint of WEBDAT well enough to say if it fits well or not.. but I
guess not as WEBDAV is .. well.. different.


Received on Monday, 27 August 2007 09:16:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:31 UTC