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

Re: Our old friends, weak ETags

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Tue, 24 Jul 2012 19:11:10 +1200
Message-ID: <500E4A8E.2020803@treenet.co.nz>
To: ietf-http-wg@w3.org
On 24/07/2012 6:39 p.m., Eric J. Bowman wrote:
> "Adrien W. de Croy" wrote:
>> a) does anyone actually use them?
>>
> Yes.
>
>> b) do they work?
>>
> I've never heard that they don't, nor run into any problems using them.
>
>> c) do we still need them?
>>
> Yes, otherwise I have to cache-expire for all changes to resource state,
> without the option to declare certain changes insignificant.  Take a
> "weblog entry" resource which includes a # of comments counter, with a
> link to a comment thread.  XHR is used to synch the count, eventually.

What type of server do you have which does not send strong ETag on 
binary-level changes anyway?

If a cache called in asking for updates with one of your weak-ETag would 
your server send a new copy or a 304 even if some changes had taken place?
    If its going to emit a new copy why bother sending W/ in the first 
place? a new Etag can goes out and the cache is refreshed with that 
immediately.
    If its not going to emit a new copy on request, why not just send 
the old strong ETag? are you emitting 304 with a different weak-ETag?

  ... Range requests that make it to the origin make things weird, but 
they can be special-cased to either change the ETag to something more 
current before handling, or to use an old copy from which the ETag was 
generated.

> I only change the Etag if the entry itself is edited.  Since metadata
> about the entry may change in the meantime, which isn't significant
> enough to warrant a new Etag in my caching scheme, I preface with W/ to
> indicate variance from the origin server not requiring cache expiration,
> i.e. semantic equivalence.

I assume you mean meta data inside the object itself (that counter, 
keywords list etc) ?

AYJ
Received on Tuesday, 24 July 2012 07:11:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 24 July 2012 07:11:51 GMT