- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Mon, 29 Apr 2013 16:49:36 -0500
- To: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CACuKZqFAyZ4VMfbHnF=SnopZ6PmVqj0R0a8h3whU=gSe7Ky4jg@mail.gmail.com>
On Mon, Apr 29, 2013 at 2:33 PM, Ben Niven-Jenkins <ben@niven-jenkins.co.uk>wrote: > Section 6.6 of p1 states: > > A server that sends a close connection option MUST initiate a > lingering close of the connection after it sends the response > containing close. The server MUST NOT process any further requests > received on that connection. > > A client that receives a close connection option MUST cease sending > requests on that connection and close the connection after reading > the response message containing the close; if additional pipelined > requests had been sent on the connection, the client SHOULD assume > that they will not be processed by the server. > > The last sentence can be interpreted one of two ways: > 1) The client SHOULD assume the additional pipelined requests will NOT be > processed by the server and therefore can happily re-try them knowing the > server has not processed the previous ones. > > 2) The client SHOULD NOT assume the additional pipelined requests will be > processed (which implies the client simply can not know whether the server > has processed them or not). > > As the client has no way of knowing whether the server may have processed > them or not (e.g. the client may be talking to a proxy that has already > relayed the pipelined requests to the origin and done so before the proxy > was aware that it wanted to close the connection on this response) I would > suggest rewording the last sentence quoted above: > > OLD: > the client SHOULD assume that they will not be processed by the server. > NEW: > the client SHOULD NOT assume that they will be processed by the server. > > Agreed; an origin server may also process pipelined requests concurrently, so request#2 may have been processed when response#1 causes Connection:close. > > Thanks > Ben > > >
Received on Monday, 29 April 2013 21:50:03 UTC