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

After some discussion with Scott Lawrence, and Richard L. Gray, we
discovered a problem with the current description of the 100 (Continue)
code and how it interacts with TCP and pipelining in section 8.2.

The problem was brought up in a discussion regarding the necessity of
sending a date header with a 100 code. As this will be sent in a separate
mail then please do not comment on this here.

The question was whether a client MUST wait for a 100 (Continue) code
before sending the entity body in a PUT or a POST request or whether it can
go ahead without waiting. Currently the latter is allowed in section 8.2
although the description is somewhat confusing. Scott found an earlier
reference to a discussion regarding this at

	http://www.ics.uci.edu/pub/ietf/http/hypermail/1997q2/0059.html

The problem is that this may force a client to close a connection
prematurely or may cause a TCP reset which will cause parts of the server's
response to get lost. This is also described in the "HTTP Connection
Management" draft by Jim Gettys and Alan Freier, section 8.

	http://www.ics.uci.edu/pub/ietf/http/draft-ietf-http-connection-00.txt

The 100 (Continue) was introduced in order to avoid this problem along with
the requirement that servers don't close the incoming connection before it
has some  idea of the client having received the response. 

So the question is: Is it enough to rely on the half-close of the
connection or should the client wait for a 100 code before sending the
body? The first situation may be faster in some cases as all the data is
sent up front and a PUT or POST request can be pipelined. But if the server
does not accept the request, the data will be discarded and the client must
resend it anyway. Another disadvantage is that the client is forced to
close the TCP connection if it has not completed sending the message and
open a new connection in order to retry the request.

Waiting for the 100 (Continue) is the more conservative method as it will
always work even if the server does not support half-close connections.
Also, it avoids that the data has to go over the wire more than once and as
both the client and the server is in a well-known state, they do not have
to close the connection.

I think, we are coming down on the side saying that a client SHOULD wait
for a 100 (Continue) code before sending the body but can send the whole
thing if it believes that the server will react properly. There should also
be a compatibility note with HTTP/1.0 servers. When talking to a HTTP/1.0
server, the only way a client reliably can avoid a TCP reset is to send the
headers and pause before sending the body.

Comments?

Henrik
--
Henrik Frystyk Nielsen, <frystyk@w3.org>
World Wide Web Consortium
http://www.w3.org/People/Frystyk

Received on Tuesday, 10 June 1997 09:47:01 UTC