etags and the lost update problem

2007-08-01 @ 21:59#

i've committed to strong support of ETags for my exyus web framework. so far, i've implemented ETags for GET/HEAD methods with solid success. i even implemented a consistent use of Cache-Control:nocache to help manage updates to the cache and keep the ETags up-to-date. that's been relatively easy and i could see the benefits right away on the server's response-time and bandwidth reductions.

but now i want to step up to the next level of ETag support - for PUT, POST, and DELETE. i'm finding thsi a bit more challenging, tho.

first, ETags can be used for PUT to make sure no-one else has PUTed an update to the resource over top of you. it's a great solution to the lost update problem. i think i understand that ETags can also be used to validate POST methods (did anyone save this exact resource already?) and DELETE methods (did someone already remove this item?), but the details are a bit sketchy.

second, there are some niggling details of using ETags for PUT/POST/DELETE that i need to face. for example, i currently generate ETags using an MD5 hash of the content of the resource. and i store that in the cache object for that resource (and no where else). that means my PUT/POST/DELETE ETag checking will fail unless the item is already in the cache - bummer. so i need to adjust my storage model to always hold an ETag of the resource. i can do that - just will take some additional work.

in fact, i am currently only caching completed XHTML objects - not the underlying data resources used to assemble the XHTML. that's a simple way to handle it right now. but it will mean some basic changes to the way the framework deals with caching in general. and once i have ETags for all resources, supporting PUT/POST/DELETE ETags will be relatively easy. i guess that's the 'big gulp' i need to take before i jump into this all the way.

UPDATE: 2007-08-02

the topic of ETags for DELETE just popped up on the atom list today - just what i was thinking about! turns out the consensus is that ETags on DELETE, while possible, are a bit over the top. that means the real focus for ETags continues to be for use with PUT to prevent lost updates. fwiw, no talk about ETags w/ POSTS - i suspect for the same reason as DELETE. possible, but not all that helpful.

code