Subject: Fwd: New Version Notification - draft-dusseault-http-patch-15.txt

From: Mark Nottingham <[email-masked]>
Date: Fri, 16 Oct 2009 10:48:37 +1100

>
>
> New version (-15) has been submitted for draft-dusseault-http- 
> patch-15.txt.
> http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-15.txt
> Sub state has been changed to AD Follow up from New Id Needed
>
> Diff from previous version:
> http://tools.ietf.org/rfcdiff?url2=draft-dusseault-http-patch-15
>
> IETF Secretariat.

--
Mark Nottingham     http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 16 Oct 2009 13:33:57 +0200

Mark Nottingham wrote:
>>
>>
>> New version (-15) has been submitted for 
>> draft-dusseault-http-patch-15.txt.

Looks good to me, except for one thing I mentioned before (see, for 
instance, 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0174.html>):

>    Collisions from multiple PATCH requests are more dangerous than PUT
>    collisions, because a patch document that is not operating from a
>    known base point may corrupt the resource.  Clients wishing to apply
>    a patch document to a known entity can first acquire the strong ETag
>    [RFC2616] of the resource to be modified, and use that Etag in the
>    If-Match header on the PATCH request to verify that the resource is
>    still unchanged.  If a strong ETag is not available for a given
>    resource, the client can use If-Unmodified-Since as a less-reliable
>    safeguard.

Recommending the use of timestamps instead a potentially available weak 
etag simple does not make sense. After all, the server is minting the 
etags, and it also controls what it accepts in conditional PATCH 
requests. Let it decide what's right.

BR, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 19 Oct 2009 11:21:26 -0700

On Fri, Oct 16, 2009 at 4:33 AM, Julian Reschke <[email-masked]> wrote:

> Recommending the use of timestamps instead a potentially available weak etag
> simple does not make sense. After all, the server is minting the etags, and
> it also controls what it accepts in conditional PATCH requests. Let it
> decide what's right.
>

It looks to me like RFC2616 forbids this even if the server could
figure out what's right.

Section 14.26 says "The weak comparison function can only be used with
GET or HEAD requests."  So in a PATCH, we'd have to use strong
comparison.

Section 13.3.3 defines strong comparison:  "in order to be considered
equal, both validators MUST be identical in every way, and both MUST
NOT be weak."

Thus, a weak ETag could never successfully be used in a PATCH
operation, because weak comparison is forbidden and strong comparison
must fail.

We could include an explanation of how this is forbidden in the PATCH
draft, if you think that would help.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Mon, 19 Oct 2009 20:39:04 +0200

> GET or HEAD requests."  So in a PATCH, we'd have to use strong

We fixed this in HTTPbis (see 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/116>), and 
furthermore, WebDAV's "If" header never had that limitation.

So my proposal would be to stay silent on this, and let the base spec 
define it.

> ...

BR, Julian

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 19 Oct 2009 14:43:50 -0500

> So my proposal would be to stay silent on this, and let the base spec

I agree, but IMO, there should *never* be a fallback to Last-Modified
because Last-Modified only has 1-second resolution. If the server supports
PATCH then it can definitely provide an ETag.

Regards,
Brian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 19 Oct 2009 17:05:57 -0700

> PATCH then it can definitely provide an ETag.

1-second resolution is as good as nanosecond resolution as soon
as that second is history, and in practice both are useless for
tagging dynamic content that is generated during a response.

Using last-modified as a fallback is always better than not
using any conditional at all.

....Roy

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 19 Oct 2009 20:38:27 -0500

Roy T. Fielding wrote:
> >> So my proposal would be to stay silent on this, and let the base
> >> spec define it.
> >
> > because Last-Modified only has 1-second resolution. If the server
> > supports PATCH then it can definitely provide an ETag.
> 

Not really. If you have nanosecond resolution then you can have
monotonically increasing (thus *unique*) timestamps on every resource.
Actually, I often implement ETags that way. With one-second resolution you
can get something similar by sleeping during an edit until the timestamp
changes, I guess.

> using any conditional at all.

Yes, well I was thinking that the server should just refuse all requests
without an If-Match header. Unconditional PATCH makes very little sense for
most uses. I guess section 2.2 already allows a server to do that (by
returning a 409 response).

Regards,
Brian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 19 Oct 2009 19:20:03 -0700

> monotonically increasing (thus *unique*) timestamps on every resource.

The only way you are going to get that is by restricting the
resource to a single server, single CPU, and critical sections
or locking.  And if you are going to go to that trouble, you
might as well have a strong versioning back-end with real etags.

> can get something similar by sleeping during an edit until the  

Not very popular with customers.

> returning a 409 response).

There is nothing stopping the patch format from including a
strong version indicator, content hash, or even a context-based
collaborative merging mechanism in the format itself.  The notion
that PATCH must use conditionals is absurd given that the original
idea came from the patch command that intentionally supports
non-overlapping edits in any sequence.

....Roy

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 19 Oct 2009 22:33:12 -0500

> non-overlapping edits in any sequence.

Yes, of course. I overlooked the obvious there. 
Regards,
Brian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 22 Oct 2009 13:53:43 +1100

So, are any changes in the draft necessary, in your collective opinion?

---

From: "Brian Smith" <[email-masked]>
Date: Thu, 22 Oct 2009 01:07:23 -0500

> 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