W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: Rechartering HTTPbis

From: Willy Tarreau <w@1wt.eu>
Date: Thu, 26 Jan 2012 15:01:47 +0100
To: Adrien de Croy <adrien@qbik.com>
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
Message-ID: <20120126140147.GF8887@1wt.eu>
On Fri, Jan 27, 2012 at 02:04:51AM +1300, Adrien de Croy wrote:
> In our case, we always send complete chunks.  At the point where we 
> decide to send a chunk, we have some data, and we know its length, and 
> we have decided to send it.
> 
> So the signal it would always fall on the start of a new chunk, e.g. we 
> scan, determine the content to be malware, and so the next chunk sent 
> would be 0 and signal an abort due to malware.

OK, I see, this is because you're doing deep content analysis.

> A close would then be less ambiguous, since nothing explicit was 
> communicated, the client could then more reliably assume it was a 
> transient network error.
> 
> I can't really think of a requirement to abort part way through a 
> chunk.  Not in this scenario anyway.

Probably in your case you never emit truncated chunks, but over the
wire it happens for a variety of reasons, including timeouts and TCP
aborts via active components (TCP proxies and/or firewalls) as I
indicated in a previous example.

> If the intermediary is re-chunking then it can easily get around this issue.

But many have no reason to re-chunk if they're just forwarding data.

Willy
Received on Thursday, 26 January 2012 14:02:35 GMT

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