The plan was to include something like an sha1 hash of the original file in the response headers. Then once the file has been decoded you can check to make sure it matches. If not you can resend the request without the black hash header and get the file the oldfashioned way.<br>
<br>Toby<br><br><div class="gmail_quote">2009/4/1 Martin Langhoff <span dir="ltr"><<a href="mailto:martin.langhoff@gmail.com">martin.langhoff@gmail.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;">
<div class="im">On Tue, Mar 31, 2009 at 8:32 PM, Toby Collett <<a href="mailto:thjc@plan9.net.nz">thjc@plan9.net.nz</a>> wrote:<br>
> We are only using 30 bit hashes, so even if it was a perfect hash it is<br>
> possible you could get a collision. Having said that our collision space is<br>
> only the single web request, so should reduce chances of error.<br>
<br>
</div>IIRC, if rsync thinks there was a collision on the weak hash, it rolls<br>
again through the file with the weak hash and a different seed.<br>
<br>
Maybe we could include a differently seeded fingerprint?<br>
<br>
Is that what you were thinking?<br>
<div><div></div><div class="h5"><br>
cheers,<br>
<br>
<br>
<br>
m<br>
--<br>
<a href="mailto:martin.langhoff@gmail.com">martin.langhoff@gmail.com</a><br>
<a href="mailto:martin@laptop.org">martin@laptop.org</a> -- School Server Architect<br>
- ask interesting questions<br>
- don't get distracted with shiny stuff - working code first<br>
- <a href="http://wiki.laptop.org/go/User:Martinlanghoff" target="_blank">http://wiki.laptop.org/go/User:Martinlanghoff</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>This email is intended for the addressee only and may contain privileged and/or confidential information<br>