Re: Why MD5 Headers are Imperative

Lisa Dusseault wrote:
> [snip]
> There's also a class of mechanisms that solve both use cases at the cost
> of some extra complication: let the client discover if a known
> resource's change state is major, minor or none [1].  Some clients will

I'm just thinking off the top of my head here so this may not make much
sense, but....

One possible approach to this is to put weak entity-tags to use.
Specifically, when I GET an entry, it would return a strong entity tag
(e.g. ETag: "foo1").  That entity tag would change every time the
resource has been updated in any way.  So, if I include a If-None-Match:
"foo1", I'll get all updates, regardless of whether or not they are
considered "significant".

However, if I only want "significant" updates, I could convert the etag
to a weak etag, e.g. If-None-Match: W/"foo1".  This would roughly
translate to "give me a response only if the entity has been modified in
a semantically significant way".  It's up to the server to determine
what "semantically significant" means just as it is up to the server to
determine when to change the value of atom:updated.

  POST        > significant update
  GET         > returns entry with new etag
  PUT         > insignificant update
  GET W/etag  > returns not modified or precondition failed response
  PUT         > significant update
  GET W/etag  > returns entry with new etag

- James