Re: 1xx Clarification

Regarding the 100 response, Scott Lawrence writes:

>  The only apparent purpose we could find in the RFC for the 100
>  response was in a discussion of client retry behaviour when the
>  connection closed before the client had finished sending the body of
>  a POST:

I think this can be blamed on reducing the HTTP/1.1 description to
those elements we already knew would be needed.  The general class of
1xx responses was intended to carry asynchronous information from
the server to the client.  I reintroduced them after talking to TimBL
when I was at the W3C, but somewhere in the year between that conversation
and the final call we overly contrained the definition of 1xx.
I will try to formulate a new description, along with an update to
the "treat unrecognized responses as the x00 response of that class"
rule which is insufficient to describe what was intended.

>  We would actually prefer to see this set of rules made more general
>  in that we'd like it to apply to any POST, not just one being
>  retried (which may or may not have been what was intended).

The 100 response must be sent by an HTTP/1.1 server upon receipt of
any HTTP/1.1 request containing a message body, after it receives the
header fields and determines that it wishes to receive that body.  The
RFC 2068 says this in section 8.2, but in a rather confusing way.

>  As to [Yaron's] suggestion above, I don't really see the point (we
>  certainly won't be sending all those extra responses), but since it
>  specifies only client behaviour we don't care much.

The client should not care either, since it should be ignoring any
1xx class of response.  A client that is not looking for such a response
will simply see it (and ignore it) upon its next request, or never see
it at all if it just drops the connection.

.....Roy

Received on Sunday, 13 April 1997 18:26:09 UTC