Use If-Range instead of If-Match/If-Unmodified-Since for partial requests.

chrome/common/extensions/api/downloads.idl

Index: chrome/common/extensions/api/downloads.idl
diff --git a/chrome/common/extensions/api/downloads.idl b/chrome/common/extensions/api/downloads.idl
index 9e0f26bdf3cff012af870257ca8fa0f9f373d4a8..95802fc58f8dd848432af247b7d141f3e66570f2 100644
--- a/chrome/common/extensions/api/downloads.idl
+++ b/chrome/common/extensions/api/downloads.idl
@@ -55,7 +55,6 @@ namespace downloads {
     NETWORK_INVALID_REQUEST,
     SERVER_FAILED,
     SERVER_NO_RANGE,
-    SERVER_PRECONDITION,

[Devlin, 2015/12/02 17:18:27]

Unfortunately, we expose these enums on the api object, so this would have the
potential to break code if anyone used
chrome.downloads.InterruptReason.SERVER_PRECONDITION, this would break.

Luckily, it looks as though no one does, so this should be safe.  But just as
FYI that, in general, we shouldn't be doing this.

[asanka, 2015/12/02 17:23:52]

Yup. See comment #12 (relevant portion pasted below):

---
  Note that this change causes "SERVER_PRECONDITION" to no longer be recognized
as an InterruptReason. This affects search() and erase() calls which use a
DownloadQuery that specifies an 'error' field of 'SERVER_PRECONDITION'. This
shouldn't happen because the SERVER_PRECONDITION interrupt reason is an
ephemeral state during download resumption and was not expected to be set on a
download in a way that search() and erase() could've observed it. 

  I'm removing it because we will now never set this interrupt reason on a
download. In the longer term it would be great if we could remove the specific
interrupt reasons from the public API (probably infeasible) because they are
exposing implementation details in a way that is already causing problems.
---

     SERVER_BAD_CONTENT,
     SERVER_UNAUTHORIZED,
     SERVER_CERT_PROBLEM,