Re: 'PUT' transaction reconsidered (was Re: two-phase send concerns )

Roy T. Fielding:
>
>This is interesting analysis, but doesn't apply to what I said.
>RTTs are not sufficiently important for the two-phase methods for them
>to be the measure of what is "best".  What is important is:
>
>   1) reliability (which boils down to both sides eventually knowing
>      what happened)
>
>   2) not sending unwanted data over the wire (if possible).
>
>I agree that an optimistic approach is capable of handling (1).
>However, it is not capable of handling (2).
>
>In most cases, this difference is trivial.  However, some security-related
>systems consider the ability to refuse a vulnerable operation before it
>occurs to be a showstopper.

Interesting point.  However, the two-phase send that is now in the 1.1
draft cannot reliably do (2) either.  If the `vulnerable operation
refused' response takes longer than 5 seconds to make and transmit,
the client will proceed with the vulnerable operation anyway.  And a
determined attacker can easily cause a 5 second delay by bombing the
server with ping packets (this is a tried and tested means of attack
in the IRC world).

So if we want to cater for this kind of security-related systems, we
have to throw out the 5 second delay.  I would consider that a
showstopper any kind of smooth upgrading from 1.0 to 1.1.

I already have my doubts about upgrading from 1.0 to 1.1 even with the
5 second delay.

>  Also, some networks will require the user
>to pay by the amount of data sent, regardless of whether that data was
>initially rejected by the server.

That may be true, but waiting for an extra RTT in each POST is not
free either.  With dial-up networks, you pay for connect time, so each
RTT costs.

Roy, I'm sorry, but if matters were put to the vote now, I would vote
against 2-phase sends.  You have failed to convince me

 a) that the pessimistic approach is superior to the optimistic approach

 b) that we even need either approach at all.  Do we really need to
    prevent wasteful uploads of unwanted data at the HTTP protocol
    level?  Would this actually save any meaningful amount of
    bandwidth?  Until we get far better caching of downloads, it would
    not.

Koen.

Received on Thursday, 28 December 1995 06:32:37 UTC