Bypass http cache for concurrent range requests.

net/http/http_cache_transaction.cc

Index: net/http/http_cache_transaction.cc
diff --git a/net/http/http_cache_transaction.cc b/net/http/http_cache_transaction.cc
index 286a526a3edb2fa39e7101e10429cf3c15b7920a..65df084731f184019accbfcc879d4931d5506c16 100644
--- a/net/http/http_cache_transaction.cc
+++ b/net/http/http_cache_transaction.cc
@@ -1382,7 +1382,17 @@ int HttpCache::Transaction::DoAddToEntry() {
     if (bypass_lock_for_test_) {
       OnAddToEntryTimeout(entry_lock_waiting_since_);
     } else {
-      const int kTimeoutSeconds = 20;
+      // Immediately timeout and bypass the cache if we're a range request and
+      // we're blocked by the reader/writer lock. Doing so eliminates a long
+      // running issue, http://crbug.com/31014, where two of the same media
+      // resources could not be played back simultaneously due to one locking
+      // the cache entry until the entire video was downloaded.
+      //
+      // Bypassing the cache is not ideal, as we are now ignoring the cache
+      // entirely for all range requests to a resource beyond the first. This is
+      // however a much more succinct solution than the alternatives, which
+      // would require somewhat significant changes to the http caching logic.
+      const int kTimeoutSeconds = partial_ ? 0 : 20;

[rvargas (doing something else), 2014/08/22 21:06:13]

What happens if this is (partial_ && new_entry_->writer &&
new_entry_->writer->range_requested_) instead?

[DaleCurtis, 2014/08/22 21:25:52]

Passes all the test the previous patch did. Do you want me to switch to that?

[rvargas (doing something else), 2014/08/22 21:44:40]

If all test pages etc behave the same, yes, I would prefer to make sure that the
first request was also for a range.

[DaleCurtis, 2014/08/22 21:45:41]

Done.

       base::MessageLoop::current()->PostDelayedTask(
           FROM_HERE,
           base::Bind(&HttpCache::Transaction::OnAddToEntryTimeout,

[scherkus (not reviewing), 2014/08/22 21:01:51]

what is the end-user visible effect caused by timing out http cache
transactions?

[rvargas (doing something else), 2014/08/22 21:10:25]

The transaction is not timed out, just waiting on the lock. The effect is that
the transaction will ignore the cache, so the response will not update the
cached entry in any way.... which may lead to consistency issues because a
future request may end up returning things "from the past" from the point of
view of the renderer.

[DaleCurtis, 2014/08/22 21:25:52]

Nothing from a casual user perspective, even for developers nothing obvious
happens in the inspector view. To my untrained eye, there's nothing obvious even
in net-internals.