W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

Re: Pipeline hinting revisited

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Sat, 13 Aug 2011 00:48:02 +1200
Message-ID: <4E452102.4080302@treenet.co.nz>
To: "Yngve N. Pettersen" <yngve@opera.com>
CC: ietf-http-wg@w3.org
On 12/08/11 19:05, Yngve N. Pettersen wrote:
> On Fri, 12 Aug 2011 08:20:13 +0200, Amos Jeffries wrote:
>> I was just thinking the 100-continue infrastructure built up over the
>> last few years with some success could be leveraged here. "Expect:
>> pipeline" and a 1xx status to indicate explicit support.
> It sounds to me like you are assuming that a server that understand the
> Expect header, but does not understand the "pipeline" expectation, will
> just return a normal 200 OK response. Unfortunately, that is incorrect:
> Such servers will return a 417 "Expectation failed" error code.
> I have seen servers send that code for the 100-continue expectation.

I'm assuming the client which chose to send it does support it. Same 
assumptions in use for rolling out 100-continue.

pipeline as a per-hop feature.

1XX - the hop supports. Explicit support. Worst case of no change in 
overall connection lag.

417 - the hop or something downstream refuses support. Explicit failure. 
More importantly _fast_ failure.

200 (or others) is a possibility. Indicating risk.
  - From hops which do not support Expect:
  - from servers which do accept pipeline but choose not to send 1XX.
  - from hops which strip the 1XX sent by a server.

There are several cases with hops hiding themselves from Via and 
otherwise removing all traces the surrounding hops could have used to 
disable the risk. We hit the exactly same situations with 100-continue 
    Does anyone have example cases of ongoing failure with that feature?

> RFC 2616, sec 14.20:
> A server that does not understand or is unable to comply with any of
> the expectation values in the Expect field of a request MUST respond
> with appropriate error status. The server MUST respond with a 417
> (Expectation Failed) status if any of the expectations cannot be met
> or, if there are other problems with the request, some other 4xx
> status.
>> That appears to nicely solve the case where pipelining is default-off
>> and enabled whenever possible.
>> It will not solve the problem of agents being aggressive in the
>> pipeline before seeing such a 1XX status. The 430 status proposed by
>> Mark resolves that case and can be emitted under the same requirements
>> as 417.

Received on Friday, 12 August 2011 12:48:42 UTC

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