Re: Our old friends, weak ETags

Amos Jeffries wrote:
>
> 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?
> 

My own.

>
> 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 the changes were insignificant, then 304, because the origin server
is sending fresh content with the same W/Etag being used to validate.
The Etag is only changed for significant updates.

>
> 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.
>

Because I don't want to refresh the cache.

>
>     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?
> 

The Etag stays the same, which is why it has to be weak; otherwise I'd
be sending byte-for-byte-different representations with the same strong
Etag, which would be incorrect.

>
>   ... 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.
> 

Or, the origin can be special-cased to ignore range requests with W/.
;-)

>
> > 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) ?
> 

Yes; without W/ I'd have to break those out as their own resources,
adding more round trips.

-Eric

Received on Tuesday, 24 July 2012 17:06:28 UTC