385984 - automated test for incremental downloading

Status: RESOLVED WONTFIX

(Core :: Networking, defect)

Description

[(not reading, please use [e-mail] instead)]

automated test for incremental downloading.

As far as I can tell, only nsUpdateService.js is using the incremental-download instance.

http://lxr.mozilla.org/seamonkey/search?string=incremental-download
http://lxr.mozilla.org/mozilla/ident?i=NS_INCREMENTALDOWNLOAD_CONTRACTID

There is the TestIncrementalDownload.cpp test, but I don't think that is hooked up to the test suite.

I'd like to add some tests for software update (possibly to http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/update/src/testnsUpdateService.js or maybe better mozilla/netwerk) so that when we do "make check" we verify that incremental downloading works.

If it were to regress, software update would be in a world of hurt.

Comment 1

[(not reading, please use [e-mail] instead)]

Say we had a bug, the mar we downloaded would not pass the size or hash checks in _verifyDownload() [2], and for a partial we'd roll over to a complete, and then we'd fail a complete as well.  I need to test to see what happens if the complete hash fails.  We should try again later, but I'll double check.  I want to make sure we'll also re-get the update.xml in this scenario.

Speaking on incremental download, is there every a case where a we swapped out a mar file in place?  I think the answer is yes.  If a client got updates.xml with one hash, started an incremental download, we change the mar, the incremental download continues, we'd fail the size or hash test, and try again.  Again, as long as we re-get the update.xml after a complete mar size/hash failure, we should be ok.

Comment 2

[(not reading, please use [e-mail] instead)]

on a related note, I think we need to fix _verifyDownload() to require a hashFunction and hashValue and to fail if we don't have one.

It looks like if hashValue was blank, as long as hashFunction wasn't valid, we'd pass the test.

I don't think we've required a hash, but I think we should (on the trunk, for fx3 and beyond.)

http://wiki.mozilla.org/Software_Update:updates.xml_Format

Comment 3

[Jeff Walden [:Waldo]]

The server doesn't do anything other than serve-it-all-at-once yet, but I think you could fake it with a custom request handler and a little non-function-local state to drive a state machine, for what it's worth.  Some pain, but byte-range download responses aren't that difficult to write -- just a status, a header, and the content, I think.

Comment 4

[(not reading, please use [e-mail] instead)]

giving back to nobody, as I'm not working on this.

Comment 5

[Robert Strong (they/them - no direct email)]

note: app update does download a few mars using incremental-download but the download file size is so small it doesn't really exercise it. What remains to be tested really should be under netwerk tests but leaving in app update in case I have time to write the test.

Comment 6

[Robert Strong (they/them - no direct email)]

There are a bunch of app update tests that use incremental download but I think it would be a good thing for the component itself to have tests so moving over to networking

Comment 7

[Patrick McManus [:mcmanus]]

this is on its way out, so we'll take the intergration test for now