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

Re: WGLC p1: Tear-down

From: Adrien W. de Croy <adrien@qbik.com>
Date: Tue, 30 Apr 2013 02:38:55 +0000
To: "Zhong Yu" <zhong.j.yu@gmail.com>, "Ben Niven-Jenkins" <ben@niven-jenkins.co.uk>
Cc: "HTTP Working Group" <ietf-http-wg@w3.org>
Message-Id: <eme39b037b-f5e0-4835-9153-c89d8d9714c7@bombed>

------ Original Message ------
From: "Zhong Yu" <zhong.j.yu@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:
>>    the client SHOULD assume that they will not be processed by the 
>>    the client SHOULD NOT assume that they will be processed by the 
>Agreed; an origin server may also process pipelined requests 
>concurrently, so request#2 may have been processed when response#1 
>causes Connection:close.

Given that it's really hard for a client to predict the future, as to 
whether a pipelined request will be processed or not, or whether a 
previous resource will return Connection: close or not, and even to tell 
whether a request will be truly without side-effects, doesn't this mean 
it's just basically dangerous to pipeline full stop?

Do we need a way for a server to communicate which requests may be made 
with impunity multiple times, and which should only be made once?  e.g. 
safe to retry or not.  then only pipeline requests that are safe to 
retry according to the server (rather than according to some assumption 
or heuristic at the client, as such things are inevitably wrong on 


Received on Tuesday, 30 April 2013 02:39:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:10 UTC