- From: Steingruebl, Andy <asteingruebl@paypal.com>
- Date: Wed, 1 Apr 2009 10:00:40 -0600
- 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 UTC