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/http_cache.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/http_cache.cc')
| -rw-r--r-- | net/http/http_cache.cc | 1 |
1 files changed, 0 insertions, 1 deletions
diff --git a/net/http/http_cache.cc b/net/http/http_cache.cc index be9dc48..855c7e8 100644 --- a/net/http/http_cache.cc +++ b/net/http/http_cache.cc @@ -945,7 +945,6 @@ int HttpCache::Transaction::BeginPartialCacheValidation() { if (!custom_request_.get()) { custom_request_.reset(new HttpRequestInfo(*request_)); request_ = custom_request_.get(); - DCHECK(custom_request_->extra_headers.empty()); } } |