Re: Resend: HTTP Performance extension for NAV(network-based anti-virus) systems

Hi,

Thanks for the comments.

Please see inline.

At 06:41 AM 8/3/2007, Adrien de Croy wrote:


>Hi
>
>A few months back I submitted an I-D which contained proposals for 
>progress notifications.
>
>the reason I raise that, is because it considers the same scenarios 
>as your draft, i.e. it was specifically conceived to deal with 
>issues around gateway scanning.
>
>There is a problem with the approach taken by your I-D.
>
>It is concerned around the issue of event sending any of the 
>resource to the client prior to it having been verified as safe.
>
>Trying to get the client to ignore the file after it has downloaded 
>a whole heap of it isn't safe.  The file may have in fact been 
>padded out to avert such techniques, so an entire workable image may 
>have been already received by the client, which would run if executed.

This is the reason I have the following statements in the draft:

"
    For some reason, if a client doesn't receive second and third (when
    applicable) sub-parts, it MUST never store/process the already
    received data.
"

"
    Some programs like browsers' "Download Manager" start storing the
    data to disk even before the complete response is received. Such
    applications should ensure that they delete any partial data in the
    event of "Proxy response IGNORE" or when second/third body (when
    applicable) parts are not received.
"

So implementations confirming to this strictly should never 
run/process a response till the response is completely received. So 
they should not have an issue ? Please suggest.


Thanks,
Babu


>There's not really any amount of an unscanned resource that can be 
>guaranteed to be safe to send (well maybe just a few bytes).
>
>This is why we're trying to deprecate "drip-feeding" in WinGate, 
>since it's fundamentally a flawed concept, albeit necessary to 
>appease the users of browsers.
>
>I just submitted a revised draft which I'll also post here, which 
>just focuses on using interim response messages to report progress.
>
>Cheers
>
>Adrien
>
>
>babun@intoto.com wrote:
>>Hi,
>>
>>I have submitted a draft on "HTTP Performance extension for NAV
>>(network-based anti-virus) systems":
>>http://www.ietf.org/internet-drafts/draft-babu-navmime-00.txt
>>
>>This draft attempts to also solve issues in reporting download progress
>>and avoiding client connection timeout in presence of network-based
>>anti-virus/anti-spam proxies.
>>
>>Like to hear feedback on this.
>>
>>
>>Thanks,
>>Babu
>>
>>PS: Appologies for resending this. Forgot to indicate the subject in my
>>last email, hence re-sending.
>>
>>
>>
>>********************************************************************************
>>This email message (including any attachments) is for the sole use 
>>of the intended recipient(s) and may contain confidential, 
>>proprietary and privileged information. Any unauthorized review, 
>>use, disclosure or distribution is prohibited. If you are not the 
>>intended recipient, please immediately notify the sender by reply 
>>email and destroy all copies of the original message. Thank you.
>>
>>Intoto Inc.
>>
>>
>
>--
>Adrien de Croy - WinGate Proxy Server - http://www.wingate.com


********************************************************************************
This email message (including any attachments) is for the sole use of the intended recipient(s) 
and may contain confidential, proprietary and privileged information. Any unauthorized review, 
use, disclosure or distribution is prohibited. If you are not the intended recipient, 
please immediately notify the sender by reply email and destroy all copies of the original message. 
Thank you.
 
Intoto Inc.