W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

RE: Pipelining in HTTP 1.1

From: Steingruebl, Andy <asteingruebl@paypal.com>
Date: Wed, 1 Apr 2009 10:00:40 -0600
Message-ID: <A4CC0718BF5AB24C85ED0B6F3E8982E30D4EAABA@DEN-EXM-05.corp.ebay.com>
To: "Jamie Lokier" <jamie@shareable.org>
Cc: <ietf-http-wg@w3.org>
> -----Original Message-----
> From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org]
On
> Behalf Of Jamie Lokier
> Sent: Wednesday, April 01, 2009 3:24 AM
> To: Roy T. Fielding
> Cc: Preethi Natarajan; ietf-http-wg@w3.org; Jonathan Leighton; Paul D.
> Amer; Fred Baker (fred)
> Subject: Re: Pipelining in HTTP 1.1
> 
> Roy T. Fielding wrote:
> > or even extend HTTP
> > such that the request/response contains some form of matching ID.
> 
> I did this in an application-specific extension of HTTP, and learned
> something not obvious to me.
> 
> Beware if you allow reordering and really use it, you can get into
> deadlock or unbounded-buffer-needed scenarios, unless you also
> implement some kind of per-ID flow control.
> 
> I found interleaving HTTP-style chunks, labelled with a
> request-response ID, and per ID receive windows, works well.  Many of
> the annoying problems of HTTP pipelining go away.
 
Out of curiosity did you just use sequential ID's to track this, or
something more like a GUID?  Several folks have been toying around with
protocol-level changes to mitigate/prevent Response-Splitting attacks
and being able to tie request+response is critical.

Not that webapps should have this vulnerability, but it wouldn't really
be possible with strict 1:1 correlation between request and response.

- Andy
Received on Wednesday, 1 April 2009 16:01:25 GMT

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