Re: 1xx Clarification

YG> It seems a clarification is in order. As such I propose that the
YG> following paragraph be added to the end of section 10.1:
YG>
YG> 1xx responses MAY be sent independently of requests. Clients MUST always
YG> be able to accept 1xx responses and MUST ignore any 1xx response they do
YG> not understand. In addition, proxies MUST pass through any 1xx response
YG> they do not understand.

>>>>> "LM" == Larry Masinter <masinter@parc.xerox.com> writes:

LM> I'm really uneasy about this. I can imagine an implementation that
LM> just doesn't read from the connection at all unless there's some
LM> request outstanding, and a server that sends a 1xx 'response' [sic]
LM> without a pending request might wind up with stuff stuck in buffers
LM> that never gets read.

LM> Seems like it puts unnecessary requirements on implementations,
LM> and it doesn't seem justified. Just what ARE these unanticpated
LM> 'responses'?

  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:

     Clients SHOULD remember the version number of at least the most
     recently used server; if an HTTP/1.1 client has seen an HTTP/1.1 or
     later response from the server, and it sees the connection close
     before receiving any status from the server, the client SHOULD retry
     the request without user interaction so long as the request method is
     idempotent (see section 9.1.2); other methods MUST NOT be
     automatically retried, although user agents MAY offer a human
     operator the choice of retrying the request.. If the client does
     retry the request, the client

       o  MUST first send the request header fields, and then

       o  MUST wait for the server to respond with either a 100 (Continue)
          response, in which case the client should continue, or with an
          error status.

     If an HTTP/1.1 client has not seen an HTTP/1.1 or later response from
     the server, it should assume that the server implements HTTP/1.0 or
     older and will not use the 100 (Continue) response. If in this case

  This wait between the headers and the body of a POST is the only
  purpose we can see for a 100 response.  The only time our
  implementation sends one is after receiving an acceptable 1.1 POST.
  This is usefull in that it allows for us to reject a POST on
  authentication or other grounds, hopefully before the client starts
  sending the body (which could be large, and which the server would
  have to just throw away).  Since most of the time a POST will have
  been preceeded by a GET from the same server (to obtain the page
  containing the form), there is a good chance that the client has had
  an opportunity to know that it is dealing with a 1.1 server so it
  can know to wait.

  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).

  As to Yolands' 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.

--
Scott Lawrence                                       <lawrence@agranat.com>
Agranat Systems, Inc.                               http://www.agranat.com/

Received on Friday, 11 April 1997 06:36:31 UTC