mca blog

i kinda went a bit wonky last night with the caching review for exyus. turns out (after careful reading of RFC2616) that caching is not all that tough - just a bit detailed.

for validation caching, there are conditionals aimed at GET/HEAD and ones aimed at PUT/POST/DELETE. this makes lots of sense, actually. If-None-Match (for ETag) and If-Modified-Since (for Last-Modified) are the directives targeted for GET/HEAD methods. the others (If-Match and If-Unmodified-Since) are for handling updates on resources.

when using the GET/HEAD conditionals, you are asking the origin server to return the resource if the ETag or the Last-Modified date *does not* match. when using the PUT/POST/DELETE conditionals, you are asking the origin server to complete the task only if the ETag or Last-Modified date *does* match. this means that the RFC has a fairly decent definition of handling the "lost update" problem using ETags and/or Last-Modified (although i would only trust the ETag pattern myself).

so, for now, i am implementing the If-None-Match and Last-Modified conditionals on the GET/HEAD methods. i'll consider PUT/POST/DELETE conditionals somewhere down the line.