Re: ISSUE: MUST a client wait for 100 when doing PUT or POST requests?

On Wed, 11 Jun 1997, Henrik Frystyk Nielsen wrote:

> I can see three ways out of the problem:
> 
> 1) Add a requirement for HTTP/1.1 that servers MUST do half-closing
> connections. The problem is then to determine for how long the incoming
> connection should stay open in order to make sure that the client won't
> loose the response. At the TCP level, the only way to determine this is to
> make sure that the segment which contains the response has been ACK'ed by
> the client and received by the server. I don't know of any method to
> propagate this information to the application layer.

It is my impression that is it difficult or impossible to do a reliable
1/2 close on all TCP/IP implementations. Unless my memory is all wet, 
solving a problem with an approach which doesn't work isn't helpful.

> 2) As Paul Leach mentions, don't allow pipelining of any non-idempotent
> methods like PUT, POST, DELETE, etc. It can still be hard to recover a
> broken pipeline due to TCP RST but at least it is possible.

The pipeline isn't broken in this case because the request wasn't
pipelined. The TCP RST can be considered == to an error response which
wasn't understood.  No different than any other situation such as a 
server of network crash which leaves the client not receiving a response.
The client must deal with the situation.

> 3) Allow pipelining of PUT and POST but with the requirement that the
> client MUST wait for the 100 code before sending the body if doing so. A
> non-pipelined request does not have to wait for the 100 code. Disallow
> pipelining of other non-idempotent methods. This will in many cases save a
> RRT compared to 2).
> 
> I don't know whether 1) is realistic, 2) will work but is the most
> conservative. 3) allows for some optimization using pipelining and does not
> prevent current practice.

Current practice or what is corrently allowed? There is a difference.

The more I think about the situation, the more convinced I become that 
it is in general wrong to allow pipelining of any request following a
non-idempontent request. As I've already said, a 100 CONTINUE tells the
client that the headers weren't rejected, maybe, but that isn't what
the HTTP protocol specifies.  The protocol allows the server to
send 100 CONTINUE after the headers have been received and "not yet
rejected" which isn't the same as saying "have been analyzed and no cause
for rejection found based on what has been received".

All of the issues with TCP RST exist from an transaction integrity
perspective with or without 100 CONTINUE *UNLESS* the client waits for
the final response from the transaction.  Even then, if TCP RST
arrives or some other error on the connection occurs, the transaction
may have completed and the client not know it.

100 CONTINUE offers a possibly useful optimization when sending a
significant amount of data might require wasted resources or induce a
server to force a TCP RST. A good heuristic guideline might be to request
100 CONTINUE when the estimated data transfer time is 4 times the
estimated RTT. It does nothing meaningful I can see for transaction
integrity.


Dave Morris

Received on Wednesday, 11 June 1997 10:42:29 UTC