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

    RTTs are not sufficiently important for the two-phase methods for them
    to be the measure of what is "best".

That's a strong statement to be made without at least some elaboration.
RTTs are the only delay in the Web (except for human "think time") that
cannot be improved by technology.  (As Mike Powell once said, you can
buy better bandwidth but only God can change the speed of light.)

It may be true that PUT-like methods are not latency-sensitive, but
if so, this requires some justification.

    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.

The security issue here is new, and seems to have several components
(I'm reading between the lines in your message):

    (1) The transmission of some data that would have been rejected
    might expose it to eavesdropping.

    (2) The mere attempt to do a "vulnerable operation" that would
    be rejected could cause some havoc at the server side.
    
Am I missing any others?  Frankly, I don't buy either of these
arguments; especially, as Koen points out, the 5-second timeout
can be manipulated by an external agent (via a temporary
denial-of-service attack) but also because we ought not to be
pretending that security can be accomplished without encryption
for privacy and authentication for authorization.

    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.
    
A good point.  But even if the HTTP protocol allows the use of an
optimistic two-phase scheme (as I am suggesting), this does not mean
that it would be required (since the optimistic scheme includes the
pessimistic scheme as a backstop).  In other words, a user that was
being charged by the packet could choose to employ the pessimistic
scheme, on its own initiative.

    Given these cases exist, a pessimistic approach is "best".  This
    does not mean that the 5 second delay is the best solution -- it is
    just a way of forcing a real solution to be created.
    
Which is exactly what I think has happened: you have done us a
service by forcing us to think about the problem.  But I still
assert that the optimistic approach is "better" (perhaps not "best")
if one believes that, most of the time, RTTs do matter and servers
will not reject PUT-like methods.  And it leaves the issue of
sensitivity to usage-pricing to the transmitter of the data, not
to an a priori choice in the protocol design.

-Jeff

Received on Thursday, 28 December 1995 13:20:37 UTC