diff options
| author | hclam@chromium.org <hclam@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-09-05 01:15:45 +0000 |
|---|---|---|
| committer | hclam@chromium.org <hclam@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-09-05 01:15:45 +0000 |
| commit | d9adff2c5cc1c9b57e7acfb8259eeec19a7b951b (patch) | |
| tree | 56a3c979de4f7f7c9cd8a4eb94714c2aa3d62261 /net/http/partial_data.cc | |
| parent | 841f7a103cbd7be1cf95c4d147854355fd5bca99 (diff) | |
| download | chromium_src-d9adff2c5cc1c9b57e7acfb8259eeec19a7b951b.zip chromium_src-d9adff2c5cc1c9b57e7acfb8259eeec19a7b951b.tar.gz chromium_src-d9adff2c5cc1c9b57e7acfb8259eeec19a7b951b.tar.bz2 | |
Bug fixing for range request support in HttpCache
TEST=net_unittests --gtest_filter=HttpCache.GET_Previous206_NotModified
Step to reproduce the failure:
1. Sparse cache has data for (0 - 9)
2. Make a non-range request for the resource
3. Server replies with 304 not modified
4. User would get 304 modified while 200 is expected
The cause is that PartialData::ResponseHeadersOK requires a full specified
range to accept the response when server replies with 304. This is not a
valid assumption as the response of 304 can be caused by the cache submitting
a range request for validation purpose.
Review URL: http://codereview.chromium.org/198018
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25569 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'net/http/partial_data.cc')
| -rw-r--r-- | net/http/partial_data.cc | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/net/http/partial_data.cc b/net/http/partial_data.cc index fcd7808..1b4b575 100644 --- a/net/http/partial_data.cc +++ b/net/http/partial_data.cc @@ -179,7 +179,7 @@ bool PartialData::IsRequestedRangeOK() { bool PartialData::ResponseHeadersOK(const HttpResponseHeaders* headers) { if (headers->response_code() == 304) { - if (truncated_) + if (!byte_range_.IsValid() || truncated_) return true; // We must have a complete range here. |