This patch adds a test in the Downloads API that specifically verifies that a download fails when an HTTP/1.1 response shorter than the Content-Length is received. This depends on the behavior introduced in the HTTP channel in bug 237623. There is no test for success in the HTTP/1.0 case, since backwards compatibility checks are probably more specific to the network layer than downloading behavior.

Did you request feedback from the wrong person? I'm not familiar with this functionality.

(In reply to Daniel Holbert [:dholbert] from comment #1) > Did you request feedback from the wrong person? I'm not familiar with this > functionality. Sure, wrong feedback flag! Thanks for the prompt reply.

Comment on attachment 8390585 [details] [diff] [review] The patch Review of attachment 8390585 [details] [diff] [review]: ----------------------------------------------------------------- LGTM. Do note that patch for bug 237623 that this tests has not yet landed anywhere yet.

Now that bug 237623 has landed, this test can be added to the Downloads code.

Comment on attachment 8441355 [details] [diff] [review] Updated error code >+ do_throw("The download should have failed."); >+ } catch (ex if ex instanceof Downloads.Error && ex.becauseSourceFailed) { >+ // A specific error object is thrown when reading from the source fails. >+ } Do you want to verify that an error is indeed thrown here as the comment suggests?

(In reply to Neil Deakin from comment #5) > Comment on attachment 8441355 [details] [diff] [review] > Updated error code > > >+ do_throw("The download should have failed."); > >+ } catch (ex if ex instanceof Downloads.Error && ex.becauseSourceFailed) { > >+ // A specific error object is thrown when reading from the source fails. > >+ } > > Do you want to verify that an error is indeed thrown here as the comment > suggests? Hm, yes, why the question? Is the current comment unclear?

(In reply to :Paolo Amadini from comment #6) > Hm, yes, why the question? Is the current comment unclear? The comment suggests that the test expects an error to be thrown, yet you don't verify that. The catch block does nothing. Are you assuming that other tests have this case covered?

(In reply to Neil Deakin from comment #7) > The comment suggests that the test expects an error to be thrown, yet you > don't verify that. The catch block does nothing. Are you assuming that other > tests have this case covered? The verification is inside the catch line itself: "if ex instanceof Downloads.Error && ex.becauseSourceFailed" That's a convenient way to verify, because if any error that does not match the expected one occurs, it will be automatically passed to the outer exception handler, which will report it in detail including the original stack trace. If the error matches, there is nothing more to do in the catch block.

Makes sense.