set content length limit if half open range request fails

content/browser/download/download_file_impl.h

Index: content/browser/download/download_file_impl.h
diff --git a/content/browser/download/download_file_impl.h b/content/browser/download/download_file_impl.h
index e786c2b38b0fff0400e9f4d9bed85463b60b22b9..eb7dbe78c7783e92733cf6920ebc6723175014a0 100644
--- a/content/browser/download/download_file_impl.h
+++ b/content/browser/download/download_file_impl.h
@@ -69,6 +69,7 @@ class CONTENT_EXPORT DownloadFileImpl : public DownloadFile {
                          const RenameCompletionCallback& callback) override;
   void Detach() override;
   void Cancel() override;
+  void SetPotentialFileLength(int64_t length) override;
   const base::FilePath& FullPath() const override;
   bool InProgress() const override;
   void WasPaused() override;
@@ -251,6 +252,10 @@ class CONTENT_EXPORT DownloadFileImpl : public DownloadFile {
   // Used to trigger progress updates.
   std::unique_ptr<base::RepeatingTimer> update_timer_;
 
+  // Potential file length. A range request with an offset larger than this
+  // value will fail. The actual file length should not be larger than this.

[David Trainor- moved to gerrit, 2017/04/03 17:47:31]

When would the file length be less than this if we set it once we're done the
half open request?

[qinmin, 2017/04/03 18:33:11]

If the length is determined upon completion of a half open request, the file
length should be equal to potential_file_length_.
However, there might not be any successful half open requests. For example, a
file is divided into 2 slices, and the slice at the end of the file finishes
first. If the browser crashes, we don't know whether the 2nd slices has
finished. So a new range request will be issued. That range request will fail
and setPotentialFileLength() will be called. So we can know that the 2nd slice
has already finished.

The issue now becomes whether the parallel request are always issued in a valid
range. If content-length is reliable, then we are ok. If somehow the file
changes, or the content-length is wrong, then the failing range request's offset
will give a larger value than the file length.

+  int64_t potential_file_length_;
+
   // Statistics
   size_t bytes_seen_;
   base::TimeDelta disk_writes_time_;