On Nov 15, 2009, at 12:03 PM, John C Klensin wrote:
Hi.
fwiw, I find myself strongly agreeing with what I believe is
Brian's main point, although what I infer from it may be a
little different from what he does (or may not... I'm not sure):
We should not be adopting a "patch" protocol that lacks both the
tools for, or a serious discussion of, transactional integrity.
John, HTTP is not SQL. The transactional integrity is inside
the resource implementation. The entire transaction consists
of a single request message and a single response message.
HTTP is responsible for the communication interface, not the
implementation of specific resources, and cannot proscribe a
specific transaction semantic because it is NOT WANTED by
many resources.
For example, a collaborative whiteboard in which many people
are patching at once, the patches consisting of context diffs
that are internally capable of distinguishing conflicts, would
be impossible to implement via standard etag behavior.
A non-HTTP example of that would be a Google wave resource
and its ability to compose a tree of wavelets.
Standard etag conflict resolution is not required because
it is not desirable for many applications of PATCH. For
other applications of PATCH, it is already defined by HTTP
and does not need to be reiterated here.
The fact that existing mechanisms lack such provisions is not an
excuse when new mechanisms are specified (or even when older
ones are clarified). As a look forward, the comments in this
note are intended as suggested requirements about revisions to
HTTP as well.
It seems to me that this general goal can be accomplished in any
of the following ways:
(1) Add an explicit confirmation-handshake mechanism to
PATCH.
I don't know what you mean by that. If you mean that the server
needs to provide the client with a way to confirm that the PATCH
has been applied (or not), then the mechanism already exists.
Perhaps the draft just needs to make it obvious that GET on the
same URI (with Cache-Control: max-age=0) will do that.
If you mean that HTTP should implement 2PC, then forget it.
The confirmation of commit is just as likely to be lost as
the previous message saying it is okay to commit, so all we
would accomplish is doubling the chance of failure.
(2) Add an explicit discussion of how ETAG, or some
other mechanism (such as refetching the page and
checking whether the patch was applied), can be used to
accomplish the purpose of a confirmation handshake.
I think you mean "add a discussion of error-handling when the
response message is lost due to server or connection failure"
to section 2.2.
(3) Add an explicit Security Considerations discussion
about the risks associated with either assuming a patch
has properly occurred without verifying that fact in
some way or of re-issuing a PATCH command without
verifying that it had not been applied. This discussion
must including a discussion of proxies and caches to be
sufficient.
How is that a security consideration?
Note that the third is not exclusive of the other two; it would
probably still be desirable and might be necessary.
Whatever is done, it must be in the document itself and must be
explicit: comments on the mailing list about mechanisms that
might be usable for the purpose are not, IMO, sufficient for a
standards-track document.
Perhaps we should add these for discussion in HTTPbis, part 4.
Regarding future versions of HTTP, there is no general
solution to the lost-confirmation-message problem in
distributed networks. The one I described (providing
a status URI before the action is attempted) can be done
using a standard Link relation in HTTP, HTML, or by using
dynamic javascript within the HTML. All of those can be
done right now, without changing HTTP. Note that those
are more applicable for POST, however, since PATCH is
confirmed via GET on the same URI, by definition.
If the IESG wants to add such a link relation to Mark's
draft currently in last call (I think) or within the link
relation registry it defines, I'm all for it.
....Roy
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf