Byte range requests sometimes omits range header if cache is enabled
Reported by
mind.bla...@gmail.com,
Oct 16 2017
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Run this project (https://github.com/bertofer/chromium-byte-range-bug) It does a request to a large file hosted in my server. Should appear with any other file in servers supporting range requests. What is the expected behavior? The expected behaviour is that all requests are sent to the backend with the range of bytes requested from code. What went wrong? Sometimes, the range header is being removed after trying in the cache. The two files attached show one working request from the net-internals events, and one that is not working. You can see, in the not-working version, how the original range header (that appears on the request to the cache) is removed when doing the request to the backend. Did this work before? N/A Chrome version: 61.0.3163.100 Channel: stable OS Version: OS X 10.12.6 Flash Version: - Disabling cache from the network devtools makes this bug disappear. - Changing the interval of the requests also makes the bug disappear, it only appears with an interval so small that requests overlap each other. - My guess is, the cache is not properly handling caching of byte ranges, as the key is the URL itself, but with range requests, different responses are received from the same URL. An error occurs from different requests to the same URL simultaneously.
,
Oct 17 2017
,
Oct 17 2017
It would be good to know if this issue happened earlier than M61 or not. If the issue happened earlier as well, it will be independent of the cache lock fix. I ran into issues installing the given project on my Ubuntu machine with some node.js/npm error. Will try on my mac next.
,
Oct 17 2017
mind.blast.session@: Can you please provide the complete netlog file that has both requests shown as overlapping. The instructions for the same can be found here: https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details
,
Oct 19 2017
,
Oct 19 2017
Work in progress CL is here: https://chromium-review.googlesource.com/c/chromium/src/+/727281
,
Oct 19 2017
This is what is happening. Looking at messages 214803(successful) and overlapping request 214808(failed). The first transaction dooms the entry after receiving the headers and before writing the headers to the entry in ValidatePartialResponse() by invoking DoomPartialEntry(). DoomPartialEntry() dooms the entry but does not restart the queued transactions. Thus the next transaction gets added to the entry and starts reading the headers but could not since nothing was written. At that point it is not getting back its range header restored and thus the issue arises. The fix does a cleaner restart of the transaction as soon as the entry is doomed where it gets its range header restored as well. In general it does make sense to restart the queued transactions when the current entry is doomed.
,
Oct 19 2017
Tested that after the fix, the given project at https://github.com/bertofer/chromium-byte-range-bug is working correctly. No transaction that comes with a range header goes to the network without the range header.
,
Oct 20 2017
Was this caused by the recent HC::T changes, or is this a pre-existing bug?
,
Oct 20 2017
Looks like the bug existed earlier but shows up more now because of the possibility of a transaction being in headers phase while the other starts to write the body.
,
Oct 23 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f41232c768c7f9ed762e3a582bd5daed7dd074d0 commit f41232c768c7f9ed762e3a582bd5daed7dd074d0 Author: Shivani Sharma <shivanisha@chromium.org> Date: Mon Oct 23 08:00:51 2017 DoomPartialEntry should restart queued transactions Bug: 775014 Change-Id: Idf7c66f458290010d0dae7b7bd6f2b270b3dd107 Reviewed-on: https://chromium-review.googlesource.com/727281 Reviewed-by: Randy Smith <rdsmith@chromium.org> Commit-Queue: Shivani Sharma <shivanisha@chromium.org> Cr-Commit-Position: refs/heads/master@{#510731} [modify] https://crrev.com/f41232c768c7f9ed762e3a582bd5daed7dd074d0/net/http/http_cache.h [modify] https://crrev.com/f41232c768c7f9ed762e3a582bd5daed7dd074d0/net/http/http_cache_transaction.cc [modify] https://crrev.com/f41232c768c7f9ed762e3a582bd5daed7dd074d0/net/http/http_cache_unittest.cc
,
Oct 26 2017
|
||||
►
Sign in to add a comment |
||||
Comment 1 by csharrison@chromium.org
, Oct 16 2017Components: -Internals>Network Internals>Network>Cache