Re: Rechartering HTTPbis

Hi Adrien,

On Fri, Jan 27, 2012 at 01:14:11AM +1300, Adrien de Croy wrote:
> 
> re signalling an abort.
(...)
> 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.

I've already thought about this too, including by sending 100 which is
supposed to be harmless.

> 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.

If the file is truncated, it should not be rendered/delivered/executed
or whatever.

> 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.

Then you need some out-of-band to do this. One again, closed connections
appear anywhere in the stream for a wide range of reasons. Too large MSS
which does not pass via some gateways, IPS dropping some packets due to
false positive matches, temporary lack of connectivity (wifi/wimax/3g/sat)
etc... The issues happen at the network level in the middle of data, so
whatever you'd send would be interpreted as part of the missing data
unless you can send it on a chunk boundary.

Imagine this simple scenario :

  +------+    +-------+        | ~ ~ ~ ~ ~ ~ |      +-----+
  | user |----| proxy |--------+   WIMAX     +------| ISP |
  +------+    +-------+       /|\           /|\     +-----+

Lack of connectivity between the proxy and ISP in the middle of a transfer
can only be detected by the proxy which has no way to report that within
the data stream to the user without padding the current chunk.

In fact, it could. We could decide that the X last bytes before a close
are *always* a status report. Still there will be a number of places where
this rule will not be applicable (mainly TCP relays, NAT gateways emitting
RSTs, ...) and this could cause much more confusion than today.

I really fail to get why we have a problem right now because chunking makes
it safe to know that you received the last chunk or that the connection was
aborted.

> 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.

I agree but most often either this info cannot technically be communicated
because the component responsible for the close does not talk the protocol,
or it will not be communicated for a variety of administrative reasons.

Probably we should work on defining better fallbacks for error conditions.

> 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.

Provided that we can advertise a chunk. This is the point I'm trying to
make. Until the current chunk is not complete, you cannot advertise a
new one.

Regards,
Willy

Received on Thursday, 26 January 2012 12:49:58 UTC