RE: weak etags vs PATCH, was: Fwd: New Version Notification - draft-dusseault-http-patch-15.txt

Mark Nottingham wrote:
> So, are any changes in the draft necessary, in your collective opinion?

I don't think this can be finalized until the caching stuff in HTTPbis is
nailed down. For example, consider a 201 response to a PATCH request that
has the Content-Location set to the Request URI. And, unless the
cacheability parts are taken out, I don't see how this can get finalized
before HTTPbis, since it will have to reference the HTTPbis RFC instead of
RFC 2616.

Besides that, I recommend dropping this whole paragraph in the final RFC:

>  A new method is necessary to improve interoperability and prevent
>  errors.  The PUT method is already defined to overwrite a resource
>  with a complete new body, and can not be reused to do partial
>  changes.  Otherwise, proxies and caches and even clients and servers
>  may get confused as to the result of the operation.  PATCH was
>  mentioned in earlier HTTP specifications, but not completely defined.

This is basically answering the question "why should we write this RFC?"
which doesn't really matter once the RFC is published. Also, it uses PUT as
a strawman to justify its existence without even mentioning that POST is a
superset of its functionality. 

Also, the statement "Collisions from multiple PATCH requests are more
dangerous than PUT collisions ..." is not always true, and in many very
common cases (diff/patch 3-way merge) is actually false, as Roy mentioned. I
think that whole paragraph could go as well. The definitions of PUT and
DELETE and POST do not have any statements like that, but obviously it could
be disastrous for an application to DELETE a resource on the false
assumption that it hasn't changed since the last time it looked at it.

This draft doesn't even contain an actual working example. I think it should
have an example using the default patch(1) format.

Finally, has anybody worked through how a complementary DIFF method would
work, to make sure that such a DIFF method would work well in conjunction
with PATCH? I would think that the addition of DIFF would have huge
implications for how caching works for non-GET methods, including PATCH.
And, if it's been decided that DIFF isn't needed because GET can be used
instead, then why doesn't the same apply for PATCH vs. POST?

Regards,
Brian

Received on Thursday, 22 October 2009 06:07:51 UTC