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:52:49 +0000
To: "Mark Nottingham" <mnot@mnot.net>
Cc: "Zhong Yu" <zhong.j.yu@gmail.com>, "Ben Niven-Jenkins" <ben@niven-jenkins.co.uk>, "HTTP Working Group" <ietf-http-wg@w3.org>
Message-Id: <em8250d35a-13c2-4842-a118-d69ff0da24b1@bombed>

------ Original Message ------
From: "Mark Nottingham" <mnot@mnot.net>
>On 30/04/2013, at 12:38 PM, Adrien W. de Croy <adrien@qbik.com> wrote:
>>  ------ 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:
>>>  OLD:
>>>     the client SHOULD assume that they will not be processed by the 
>>>  NEW:
>>>     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 occasion).
>That's built into the method of the request...
that's what I meant by assume.

UA authors might assume GET is idempotent.  It doesn't stop web 
developers from writing sites that have significant side-effects on GET. 
  Getting these people to indicate safety of retrying is another problem. 
  I guess this is one reason why pipelining isn't that widespread yet.  
Lots of problems with it.



>>  A user agent should not pipeline requests after a non-idempotent 
>>method until the final response status code for that method has been 
>>received, unless the user agent has a means to detect and recover from 
>>partial failure conditions involving the pipelined sequence.
>Mark Nottingham http://www.mnot.net/
Received on Tuesday, 30 April 2013 02:53:17 UTC

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