launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

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

Attachment: signature.asc
Description: This is a digitally signed message part