Edward Lee schrieb: > Link Fingerprints are intended for complete file downloads, but many > download managers like DownThemAll request multiple chunks in parallel > to increase throughput. The problem is what should be done with these > partial Range requests for URIs that have a Link Fingerprint? > > There's 2 choices of what to do with Link Fingerprints for Range > requests as the provider of the network channel. > > 1) Ignore the Link Fingerprint > 2) Enforce the Link Fingerprint > > (1) makes download manager providers' lives easier - things continue to > work without any changes > > (2) forces download managers to be aware of Link Fingerprints. If they > don't realize there's a concept of Link Fingerprints, transfers will > mysteriously fail when doing Range requests. This means they need to > explicitly remove the #fragment-id before requesting the transfer, but > because of this, they make the active decision to either support Link > Fingerprints by implementing it or choose not to compute the hash. > > Enforcing Link Fingerprints provides additional functionality in that > Range requests can be Link Fingerprinted. This means assuming the hash > of the specific range is known, the network channel can automatically > compute the hash to ensure it was transferred correctly. > > This could be useful with resources that provide checksum data such as > Metalinks, so not only would it let the download manager know what the > overall file checksum should be, individual parts can be given a > checksum - somewhat similar to how bittorrent has a checksum for each > piece. > > Ed
First of all, my understanding was till now, that the actual consumer (download manager, image/embedded loader) would either turn this feature on or would just be hinted somehow about the outcome of the verification without receiving an error it cannot recover from. It should be up to the consumer to decide whether he wants to support LF, and when supported to take appropriate action. In case of the download manager(s) I would imagine a "Retry/Fail(Delete File)/Ignore" question for the user, while image loader would simply not display the image. Generally enforcing the check even for "range-less" requests would probably hurt DownThemAll and similar products. There is no guarantee that the consumer will in fact retrieve the whole stream, even if he requested it from the server. dTa won't in many cases, either because a download is paused, or because of the (currently newly developed) multi-part algorithm. IIRC the imageloader, too, will use Ranges when resuming image downloads. What will happen in the case of not fully retrieved channels? I would have expected a "hint" to the consumer saying UNABLE_TO_CHECK instead of VERIFIED, CORRUPT or UNSUPPORTED. Checking ranges seems quite pointless to me. It's not the same as "piece hashes" or rolling hashes (tree hashes). There is no way to determine or dictate what ranges the client will retrieve when. So I cannot quite follow your thinking here. (2) is not even possible for range-requests. Conclusion (or simply my opinion) ---------- * Leave it to the consumer to take appropriate action. * Leave it to the consumer to even request verification. * I don't like the idea of implementing verification at channel level. I'd rather implement a new service that then might be utilized by the download manager, image loader, extensions like dTa, etc. * I read bug 377245 and second gerv's concerns. Nils _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
