Re: 1xx Clarification

Scott Lawrence <lawrence@agranat.com> writes:

>RF> The 100 response must be sent by an HTTP/1.1 server upon receipt of
>RF> any HTTP/1.1 request containing a message body, after it receives the
>RF> header fields and determines that it wishes to receive that body.  The
>RF> RFC 2068 says this in section 8.2, but in a rather confusing way.
>
>RF> The client should not care either, since it should be ignoring any
>RF> 1xx class of response.  A client that is not looking for such a response
>RF> will simply see it (and ignore it) upon its next request, or never see
>RF> it at all if it just drops the connection.
>
>  Our server does send a 100 Continue under those conditions; the rule
>  I would like to see stated more directly is that:
>
>    When sending a request with a body to a server it has reason to
>    believe implements HTTP/1.1, a client SHOULD send the headers and
>    then wait for a 100 Continue or an error status before
>    transmitting the body of the request.
>
>  the current spec essentially says this only for the case where the
>  client is retrying a request, not for the first attempt.

I believe that this is dependent on the nature of the request, and thus
should be determined by the user agent and not by the protocol.  This is
why the 100 response is required from an HTTP/1.1 server, instead of
being optional, so that a user agent can be selective in deciding whether
to wait for the round trip.

Because of interactions with HTTP/1.0 and proxies, I do not expect this
to be useful except for specialized applications, or until all HTTP/1.0
are outside the operating domain.  Nevertheless, 100 was added because
it was something that some HTTP applications needed to express, but
couldn't be expressed in HTTP/1.0.

.....Roy

Received on Monday, 21 April 1997 16:00:41 UTC