Re: 1xx Clarification
Roy T. Fielding (fielding@kiwi.ICS.UCI.EDU)
Sun, 13 Apr 1997 18:22:13 -0700
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