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

Re: Pipeline hinting revisited

From: Yngve N. Pettersen <yngve@opera.com>
Date: Fri, 12 Aug 2011 09:05:10 +0200
To: ietf-http-wg@w3.org, "Amos Jeffries" <squid3@treenet.co.nz>
Message-ID: <op.vz29ysx7kvaitl@lessa-ii>
On Fri, 12 Aug 2011 08:20:13 +0200, Amos Jeffries <squid3@treenet.co.nz>  
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.

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.
>
> IMO we should add "Expect: pipeline", 1XX and 430.  
> http://tools.ietf.org/html/draft-nottingham-http-pipeline-01 looks like  
> the right vehicle to extend and see that implemented.

IMO, if the problem with bad server and intermediate handling of  
pipelining cannot be solved within the current framework, then a new  
infrastructure, either for signaling support for optional protocol  
features or upgrading the protocol, e.g. what Mark is working on, with  
proper thoughts about what an intermediate can do wrong, need to be  
considered.

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************
Received on Friday, 12 August 2011 07:09:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:46 GMT