Re: Rechartering HTTPbis

re signalling an abort.

It's actually a very common requirement when drip-feeding data to a 
client whilst it's being scanned.

I go back to scanning for malware at a gateway.  Sometimes it seems I 
(and my customers) are the only ones interested in this application????

1 It's a requirement to collect an entire entity in order to scan it
2 It's a requirement to prevent agents and humans from timing out.

therefore it's a necessity to send something to the client, potentially 
long before you have the entire entity.  My proposal for progress 
notifications was intended to address exactly this issue.  It's safer to 
send status updates than it is to send actual unscanned entity data.  
However, in the absense of support for update notifications (e.g. with 
103 status or similar), then you have to send unscanned data.

This is an enormous hideous gaping security hole, and browser vendors 
make it worse by their behaviour (or lack thereof) when a transfer is 
aborted (by closing, currently our only option).  In short they do 
nothing, and let you execute the unscanned file.

So, if you're sending chunked to a client, and you decide you need to 
abort the connection, we need a way to signal to the client that it 
should discard what it has received.

Unless all browser vendors (except Opera at last check) change their 
behaviour to warn of an aborted transfer (for what reason they have no 
clue) then it's an ongoing problem.  But even then they are still 
guessing as to why it was aborted.  Was it a network timeout, someone 
tripped over an ethernet cable etc etc?  In the absence of real 
information, a client is probably just going to retry to get the rest.

Why make clients guess when we can make it deterministic?  A simple 
final status code on the final chunk could signal that the transfer was 
aborted, and give a decent reason along with it to drum it into the 
client that they really should discard the entity and not just try to 
fetch the rest of it.

Adrien


-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Thursday, 26 January 2012 12:14:39 UTC