launchpad-dev team mailing list archive

[Bjorn Tillenius <bjorn@xxxxxxxxxxxxx>]

On Wed, Mar 03, 2010 at 08:02:27AM +1100, Robert Collins wrote:
> On Tue, 2010-03-02 at 11:23 -0600, Deryck Hodge wrote:
> > 
> > I also think it would be nice to be able to mark an attribute as
> > ignorable for the sake of calculating the etag when we decorate
> > attributes for exporting.  If status on a bug changes, that could
> > matter to a script.  If heat changes, not so much.  Heat can't be set
> > by an external script anyway.
> > 
> > I wonder if read_only does this or could be made to do this?  I asked
> > Leonard on IRC and he wasn't sure.  He's also very busy at the moment
> > to dig further into the question.  This seems a nice solution.  But it
> > doesn't solve it for attributes that can be set. 
> 
> Speaking from an HTTP point of view...
> 
> derived aspects of an object that have *semantic* value should be
> included in the ETag; because the ETag controls caching. Read only has
> nothing to do with whether a change to a field should invalidate
> caches. 

This is a good point. The ETag should probably stay as it is, as it's
used for caching.


> For PATCH commands, they supply If-Match to only patch the object they
> think they are starting from. Its possible server side to decide that:
>  - the Etag is a recent one
>  - only readonly fields have been changed since that etag was issued
>  - so we can accept the patch

Another solution, that might be simpler, is to have two tags. One ETag
for caching, and another tag used for avoiding mid-air collisions. This
might mean that we can't use the standard HTTP headers for
mid-air-collision checking, but I don't see a big problem with that.

I suggested a new tag, since I though Robert's suggestion would be quite
hard to implement, without storing the generated Etags somewhere. But I
guess it's possible to do what Robert suggested without keeping track of
the Etags.  For example, we could calculate to hashes, one for writable
fields (let's call it WHASH) and one for read-only fields (let's call it
RHASH). We would then concatenate WHASH and RHASH to get the Etag. When
the server checks the If-Match Etag, it would only check the first part
of the Etag, the WHASH.


-- 
Björn Tillenius | https://launchpad.net/~bjornt