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

Another thought:

One way for a server to unilaterally prevent the transmission of "too
much" data before it gets a chance to check the header is for it to
advertise a relatively small TCP window.  For example, if the server
sets its receive window size to, say, 512 bytes, the client will not be
able to send more than 512 bytes beyond the point that the server has
read.  If the server decides to accept the request, it can open up the
window and let the bytes flow at full speed.  Otherwise, it can send an
error status and close the connection.

So we could use the "optimistic two-phase" scheme in the HTTP/1.1
protocol spec, and then advise people who consider that to be too
insecure to use a window-based scheme to further protect their
servers.

I'll admit right away that there are some drawbacks to this approach.
First of all, it seems to be nearly impossible in BSD-based systems to
set the receive window size before the connection has been accept()ed,
which means that a client with a large congestion window could send a
lot of data before the window shrinks.  I think this is a design
deficiency in BSD, but I don't know if it is likely to be widely
fixed.  Anyway, most clients slow-start with a 1-MSS congestion window,
giving the server some time to set its receive window down.

Second, it's probably hard to combine this with a persistent-connection
model that uses pipelining, since the client could use "excess" window
remaining from one request to start another one.  So a server that
really wants to prevent transmission of unwanted request bodies has to
stick to a single-request-per-connection approach.

Third, it doesn't prevent the client from sending at least a little of
the request content; although I think it is idiotic to base one's
security on preventing this kind of thing, people who do want to do
that might complain.

Fourth, it could introduce a few extra round-trips into the exchange
(depending on the TCP MSS).

Just a thought.

-Jeff

Received on Friday, 29 December 1995 12:02:11 UTC