- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Sat, 13 Aug 2011 00:48:02 +1200
- 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 today. 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. AYJ
Received on Friday, 12 August 2011 12:48:42 UTC