<br><div class="gmail_quote">2009/7/17 Patrick McManus <span dir="ltr"><<a href="mailto:mcmanus@ducksong.com">mcmanus@ducksong.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
it occurs to me that there is an obvious mitigation: any document with<br>
100K hash values and just 1 hit is a really poor delta and indeed<br>
probably isn't a delta at all. Any response that is _almost_ all<br>
literals should probably just make itself into all literals (or just<br>
plain 200-non-delta)..<br>
</blockquote><div><br>The problem here is that a non buffering implementation of a chunked transfer doesnt know it has only got one hash match before it starts sending the data...<br><br>Also from my limited understanding of crc sums, the excellent properties for detecting small changes seem to be very small changes (i.e. bursts of up to the hash length). Even for very similar web pages the chance of having all of the changes contained within a 32 bit range.<br>
<br>This one is a bit of a long shot, but is it possible to just send the content twice, once encoded, followed by a stream flush, and once unencoded. At the client end if they get a strong hash error they just keep receiving the rest of the content unencoded, if they get a strong hash match then they terminate the connection. This would probably play hell with caches, cause complications on the server end as you would have to buffer the whole file for appending, and chances are half the unencoded file would already be in transit by the time you killed the connection in the no corruption case, but just wondered if it would trigger any ideas from others along the same lines.<br>
<br>Toby<br></div></div><br><br clear="all"><br>-- <br>This email is intended for the addressee only and may contain privileged and/or confidential information<br>