ietf
[Top] [All Lists]

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

2009-11-13 22:48:03
On Nov 13, 2009, at 4:16 PM, Brian E Carpenter wrote:
On 2009-11-14 12:57, Roy T. Fielding wrote:
On Nov 13, 2009, at 2:26 PM, Brian E Carpenter wrote:
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.

Yes, and that is exactly what would happen even if HTTP supported
full two-phase commit, with all of its painful consequences, if the
response to commit was lost.  This is an application problem, not
a protocol requirement.  It can be "fixed" (to the degree that any
fix is possible in a distributed system) by providing the client
with a status resource within the same page as the SUBMIT, such
that the client can see the change in server state when it takes
place even if the specific 200 response is lost.  In other words,
provide the client with the information necessary to check the bill
before the final transaction is submitted.

...

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.

The use case for PATCH is requesting relative state changes to
a known resource.  The way to detect the resulting state of the
resource in case of communication error is to perform a GET
(perhaps with Range) on the same resource.  That is one of the
few benefits of defining PATCH instead of just reusing POST.

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