W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: WGLC p1: Tear-down

From: Zhong Yu <zhong.j.yu@gmail.com>
Date: Mon, 29 Apr 2013 16:49:36 -0500
Message-ID: <CACuKZqFAyZ4VMfbHnF=SnopZ6PmVqj0R0a8h3whU=gSe7Ky4jg@mail.gmail.com>
To: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:12 UTC