- 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>
------ 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 >>>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. >> >> 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. Regards Adrien > >> 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