- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 30 Apr 2013 12:48:10 +1000
- To: "Adrien W. de Croy" <adrien@qbik.com>
- Cc: "Zhong Yu" <zhong.j.yu@gmail.com>, "Ben Niven-Jenkins" <ben@niven-jenkins.co.uk>, "HTTP Working Group" <ietf-http-wg@w3.org>
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... > 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:48:38 UTC