On Tue, 2010-03-09 at 13:46 -0500, Leonard Richardson wrote: > As I read the standards, if bug_heat has changed and I try to PATCH an > unrelated field, the correct behavior is that my PATCH should fail. I > don't think this makes sense for us given the way we implement PATCH, > but it does make sense in general.
The strong ETag for patch is a SHOULD in http://tools.ietf.org/html/draft-dusseault-http-patch-16 which is fresh as of november - PATCH is still under evolution. That I-D also says that the strength of checking needed depends on the use to which PATCH is being put: appending to a log doesn't demand all clients to agree on the old log state. > I don't think anything bad will happen if we implement the two-part > ETag. The whole ETag string is in fact a strong ETag, so anything that > treats it as a strong ETag will still work. We'll just have some > server-side magic that secretly implements a weak comparison function to > make PATCH requests work. And if anyone actually tries to PATCH bug_heat > they'll still get an error. I think that a strong all-fields ETag that we can parse to get a strong mutable-fields only ETag is a great idea. -Rob
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
