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

The spec is supposed to only use uppercase MUST and SHOULD for
interoperability requirements.  There are many examples where that
is not the case now, but following bad examples is not a goal.

The *choice* of whether or not the client waits for the 100 response
is not an interoperability requirement.  If an application has reason
to expect that the server will accept the request and read the incoming
data before closing (as is the case for existing POST requests to a
CGI script) or if the application doesn't mind receiving a reset and
repeating the request at a slower rate the second time, then it does
not need to wait for the 100.  If, however, it is an application that
wants to test the waters before diving in, then it can wait for the 100.
Neither case impacts the interoperability between client and server.

This does not need to be in the protocol spec because they are decisions
made according to the nature of the application and the context of
the request.  A distributed coke machine has different requirements
from a workstation-based browser which has different requirements from
a PDA talking to a wireless station-proxy.  How an application determines
its own requirements is not our concern.

The only interoperability requirement is that the server always respond
with 100 if it receives a request indicating a message body.  This
requirement exists because, without it, the client would never have
a choice, and thus some types of information systems would not be possible
using HTTP.

.....Roy

Received on Tuesday, 10 June 1997 15:49:12 UTC