Re: Rechartering HTTPbis

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 UTC