ietf
[Top] [All Lists]

Re: Gen-ART LC review of draft-dusseault-http-patch-15.txt

2009-11-13 19:16:52
Roy,

Just a couple more comments below, and then I will have
said all I can usefully say.

On 2009-11-14 12:57, Roy T. Fielding wrote:
On Nov 13, 2009, at 2:26 PM, Brian E Carpenter wrote:
On 2009-11-13 23:35, Julian Reschke wrote:
Brian E Carpenter wrote:
On 2009-11-13 20:19, Julian Reschke wrote:
Brian E Carpenter wrote:
As far as I can tell, the proposal places the burden for ensuring
atomicity entirely on the server. However, PATCH is explicitly not
idempotent. If a client issues a PATCH, and the server executes the
PATCH,
but the client then fails to receive an indication of success due to
an extraneous network glitch (and TCP reset?), then what prevents the
client
issuing the same PATCH again? In other words, absent a two-phase
commit,
there appears to be no transactional integrity.
How is this different from PUT or POST? If you need repeatability of the
request, just make the request conditional using "if-match"...
PATCH seems more dangerous than those simply because it is partial
update of a resource, and I don't feel it's sufficient to say that
there might be a way of detecting that it has failed to complete,
if you're executing a series of patches that build on one another.
POST can be a partial update as well, for the simple reason that POST
can be *anything*. As a matter of fact, people are using POST right now,
as PATCH was removed in RFC 2616.
I wasn't involved in reviewing RFC2616 (or in the original design of POST,
even though it happened about 20 metres from my office at that time). But
yes, POST also lacks transactional integrity. Incidentally, that recently
caused me to donate twice as much as I intended to the relief fund for
the tsunami in Samoa, although the direct cause was a network glitch.

That doesn't have anything to do with POST lacking transactions.
Any server is fully capable of detecting repeated transactions
just by looking at the data sent.

Not in this case. The service was instantiated once, received
a legitimate series of POSTs, including the final one triggered
by a SUBMIT button, and then the final response code to the client
(a standard browser) vanished, for whatever reason. [Digression
about why this failure was probably caused by a NAT deleted.]
The human client simply sees a browser timeout and has no possible
way of knowing whether the SUBMIT executed. As it turns out, my credit
card bill later showed that it did.

Talking about transactional integrity in the IETF has always been
hard, for some reason. But something described as "patch" is exactly
where you need it, IMHO.
PATCH does not need to be special, and shouldn't be special. That being
said, it wouldn't hurt to clarify that PATCH can be made repeatable
(idempotent) by making it conditional.
I would make that a SHOULD and, as I said originally, be more precise
about how to use strong ETags to achieve it.

No.  The patch format may be designed to be repeatable (append).
The patch format may include its own conditions (context diffs,
before/after metadata, etc.).  HTTP is neither a filesystem nor
a database, so don't expect the protocol to interfere with
legitimate communication just because some resources might
require transactions for tightly-coupled behavior.  That is not
the protocol's job.

Given that HTTP took the stateless approach that it did,
I don't expect the protocol to embed transactional integrity.
But I do expect the protocol spec to describe in normative terms
how to detect a relatively likely type of failure. I agree
that whether that is needed depends on the use case for PATCH.

     Brian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf