W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2002

Re: HTTP If-* headers, etags

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Tue, 30 Apr 2002 09:12:30 +0200
Cc: w3c-dist-auth@w3c.org
To: Erik Seaberg <erk@flyingcroc.com>
Message-Id: <A2640A46-5C09-11D6-BBE9-00039384827E@greenbytes.de>

Am Montag den, 29. April 2002, um 19:49, schrieb Erik Seaberg:

> Jason Crawford <ccjason@us.ibm.com> writes:
>
>> One thing I was concerned about is resources whose GET output
>> changes often in hard to predict ways[....] But I think the answer
>> to that is, you don't do a PUT against the live resource.
>
> Are servers commonly expected to keep GET on a source resource bitwise
> identical with the last PUT?  It seemed transcoding, canonicalizing,

Not at all. Etags are no CRC on the content - a client cannot
calculate an ETag before the PUT.

> or other postprocessing at PUT time would be expected to routinely
> change strong ETags (in fact we do that sort of thing to deter abuse
> of a free hosting service).  Are common clients unable to accomodate
> this?

Etags are not to be touched by caching proxies. With transcoding 
proxies,
I'm not sure what they should do.

To answer your question: I don't think that any plain HTTP or WebDAV
client will be confused by rapidly changing Etags as such.

However, the other side of the coin is that it makes sense for editable
content (say a PDF document) to keep their ETag between PUTs. Clients
can then use the ETag (and are indeed encouraged to do this) to check
for unexpected changes to the document they are about to replace.

//Stefan
Received on Tuesday, 30 April 2002 03:45:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:00 GMT