summaryrefslogtreecommitdiffstats
path: root/net/http/partial_data.cc
Commit message (Collapse)AuthorAgeFilesLines
* Http cache: Add code to restart a network request when thervargas@google.com2009-12-011-1/+3
| | | | | | | | | | | | server doesn't revalidate a partially stored entry, in other words, after we issued a conditional byte range request. BUG=27276, 28850 TEST=unittests Review URL: http://codereview.chromium.org/452017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33412 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 33133 - Http cache: Add code to restart a network request when thervargas@google.com2009-11-301-3/+1
| | | | | | | | | | | | | | | server doesn't revalidate a partially stored entry, in other words, after we issued a conditional byte range request. BUG=27276, 28850 TEST=unittests Review URL: http://codereview.chromium.org/434052 TBR=rvargas@google.com Review URL: http://codereview.chromium.org/452003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33253 0039d316-1c4b-4281-b951-d872f2087c98
* Http cache: Add code to restart a network request when thervargas@google.com2009-11-251-1/+3
| | | | | | | | | | | | server doesn't revalidate a partially stored entry, in other words, after we issued a conditional byte range request. BUG=27276 TEST=unittests Review URL: http://codereview.chromium.org/434052 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33133 0039d316-1c4b-4281-b951-d872f2087c98
* Add compiler-specific "examine printf format" attributes to printfs.evan@chromium.org2009-11-201-6/+10
| | | | | | | | | | | | Functions that take a printf-style format get a new annotation, which produces a bunch of compiler warnings when you use printf impoperly. This change adds the annotations and fixes the warnings. We now must use PRId64 for 64-bit numbers and the PRIsz for size_t. Review URL: http://codereview.chromium.org/339059 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32600 0039d316-1c4b-4281-b951-d872f2087c98
* Http cache: Always preserve extra headers when dealing withrvargas@google.com2009-11-031-4/+6
| | | | | | | | | | | byte range requests. BUG=25755 TEST=unittests Review URL: http://codereview.chromium.org/339088 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30773 0039d316-1c4b-4281-b951-d872f2087c98
* Minor defense-in-depth tweak. end - start + 1 can actually go negative ifcevans@chromium.org2009-10-281-1/+1
| | | | | | | | | | | | start==0 and end==9223372036854775807, i.e. the full positive range of a 64-bit signed int. BUG=NONE TEST=NONE Review URL: http://codereview.chromium.org/346003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30363 0039d316-1c4b-4281-b951-d872f2087c98
* Http Cache: More unit tests for byte range support.rvargas@google.com2009-10-141-0/+4
| | | | | | | | | BUG=b/2071330 TEST=unittests Review URL: http://codereview.chromium.org/267101 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29035 0039d316-1c4b-4281-b951-d872f2087c98
* Handle range request on a truncated entryhclam@chromium.org2009-10-021-3/+2
| | | | | | | | | | This change will doom the truncated entry and creates a new sparse entry. TEST=unit tests Review URL: http://codereview.chromium.org/251067 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27859 0039d316-1c4b-4281-b951-d872f2087c98
* Handle reading to the end of a sparse entryhclam@chromium.org2009-10-011-0/+3
| | | | | | | | | | | | TEST=run chrome with --enable-byte-range-support --incognito and watch a video in http://tinyvid.tv/, seeking should be fine. http_cache::PartialData used to read a length of zero when reading has reached the end. The zero parameter will cause MemEntryImpl to complain about invalid argument, so early return for the case that we know we have nothing to read. Review URL: http://codereview.chromium.org/255034 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27776 0039d316-1c4b-4281-b951-d872f2087c98
* Bug fixing for range request support in HttpCachehclam@chromium.org2009-09-051-1/+1
| | | | | | | | | | | | | | | | | | | 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
* Http Cache: Add support for resuming downloading arvargas@google.com2009-09-041-4/+35
| | | | | | | | | | | | resource after the original request was interrupted. BUG=8995 TEST=unittests Review URL: http://codereview.chromium.org/197016 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25551 0039d316-1c4b-4281-b951-d872f2087c98
* Http cache: Fix the code that handles 206s when revalidatingrvargas@google.com2009-08-201-3/+0
| | | | | | | | | | | a range from the cache. BUG=12258 TEST=unittests Review URL: http://codereview.chromium.org/174039 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23881 0039d316-1c4b-4281-b951-d872f2087c98
* Http Cache: Additional byte-range support.rvargas@google.com2009-08-181-11/+59
| | | | | | | | | | | | | | | | | | | | * Now we can serve byte range requests from cached 200s. * When we receive 304 we make sure that we were expecting it. * A range request that doesn't fit the currently stored entry only deletes the entry if the server confirms that it has changed. * Make sure that LOAD_ONLY_FROM_CACHE causes cache misses for byte range requests. BUG=12258 TEST=unittests Review URL: http://codereview.chromium.org/165479 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23601 0039d316-1c4b-4281-b951-d872f2087c98
* Http cache: Extend support for byte range requests.rvargas@google.com2009-08-121-17/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Now we handle regular requests (not byte range requests) that end up reading a cached entry that stores byte ranges. In this case we create a control object (partial_), but it's byte_range_ member is always invalid because the user is not requesting a range. * Given that we may find stored 206s that are not keeping sparse data, we detect that case and handle it. * Now we may end up reading 206 from disk (and the net) and having to change the returned status to be 200 (for regular requests). * We avoid performing re-validations for each piece of stored data. Instead, we consider the whole entry to be revalidated once, and read from the cache without asking the server (as far as we can). * When processing the received headers we now consider receiving 200 and 416 (instead of 206/304) and we handle inconsistencies in the range returned by the server (from what we expect). We also handle receiving 206 when we don't expect it. BUG=12258 TEST=unittests Review URL: http://codereview.chromium.org/164304 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23123 0039d316-1c4b-4281-b951-d872f2087c98
* Http cache: Add support for ranges with an unknown start or end.rvargas@google.com2009-06-241-19/+31
| | | | | | | | | BUG=12258 TEST=unittest Review URL: http://codereview.chromium.org/147042 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19142 0039d316-1c4b-4281-b951-d872f2087c98
* Http cache: Return valid Content-Range headers for a byte range request.rvargas@google.com2009-06-221-0/+75
| | | | | | | | | BUG=12258 TEST=unittests Review URL: http://codereview.chromium.org/140015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18961 0039d316-1c4b-4281-b951-d872f2087c98
* Http Cache: First pass of byte-range requests support.rvargas@google.com2009-06-121-0/+131
This is the first pass to implement support for range requests and the asociated sparse cache entry. It is disabled by default, and requires ENABLE_RANGE_SUPPORT to be defined in order to activate the code: all the code is compiled in, but Start() bypasses the cache for range requests, and OnNetworkInfoAvailable ignores 206. Big parts are still not implemented. Most notably we are not modifying the response headers that we send to the user, so the content-range and content-length info are not correct. BUG=12258 TEST=Unit tests. Review URL: http://codereview.chromium.org/118345 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18289 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-13 05:33:56 +0000