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

[mnot]

>
>
> 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/

[Julian Reschke]

Mark Nottingham wrote:

>>
>>
>> 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/

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

[Lisa Dusseault-3]

On Fri, Oct 16, 2009 at 4:33 AM, Julian Reschke <julian.reschke@...> 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

[Julian Reschke]

Lisa Dusseault wrote:

> On Fri, Oct 16, 2009 at 4:33 AM, Julian Reschke <julian.reschke@...> 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.

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

[Brian Smith-19]

Julian Reschke wrote:
> So my proposal would be to stay silent on this, and let the base spec
> define it.

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

[Roy T. Fielding]

On Oct 19, 2009, at 12:43 PM, Brian Smith wrote:

> Julian Reschke wrote:
>> So my proposal would be to stay silent on this, and let the base spec
>> define it.
>
> 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.

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

[Brian Smith-19]

Roy T. Fielding wrote:

> On Oct 19, 2009, at 12:43 PM, Brian Smith wrote:
> > Julian Reschke wrote:
> >> So my proposal would be to stay silent on this, and let the base
> >> spec define it.
> >
> > 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.
>
> 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.

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 last-modified as a fallback is always better than not
> 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

[Roy T. Fielding]

On Oct 19, 2009, at 6:38 PM, Brian Smith wrote:
> Not really. If you have nanosecond resolution then you can have
> 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.

> 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.

Not very popular with customers.

>> Using last-modified as a fallback is always better than not
>> 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).

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

[Brian Smith-19]

Roy T. Fielding wrote:
> On Oct 19, 2009, at 6:38 PM, Brian Smith wrote:
> 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.

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

[mnot]

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


On 20/10/2009, at 2:33 PM, Brian Smith wrote:

> Roy T. Fielding wrote:
>> On Oct 19, 2009, at 6:38 PM, Brian Smith wrote:
>> 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.
>
> Yes, of course. I overlooked the obvious there.
> Regards,
> Brian
>

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

[Brian Smith-19]

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

[Nicolas Alvarez-2]

Brian Smith wrote:
> 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?

Something similar to "DIFF" is implemented via GET and extra request headers
in RFC 3229.