Support user-constructed conditional requests to HttpCache updating the cache.

These are requests where conditionalization is specified through |extra_headers| rather than through a load flag (LOAD_VALIDATE_CACHE).

The previous behavior was that such requests would disable caching. So any more up-to-date response discovered by an "if-modifed-since" request was never written back to the cache.

BUG=http://crbug.com/16199
TEST=HttpCache unit tes

Overview for how these requests are dealt with:

(1)

When starting the request, check for an "if-modified-since" or "if-none-match" request header.
If one is found:
  * let it be called |external_validation_header|
  * continue to (2).

(2)

Parse |external_validation_header| to obtain either an |etag| or a |last_modified_date|.

(3)

Read the HTTP cache entry for URL. Call the result |entry|.

(4)

Now that we have read the cache entry, check if |external_validation_header| defines a validation request for |entry|.

We cannot assume that |external_validation_header| makes sense in the context of |entry|, since the headers are free-form text originating from WebCore, and could be unrelated to the cache entry.

If any of the following are true, then |external_validation_header| does NOT define a validation request for |entry|:

  * |entry| is undefined (was not found in step (3)).
  * |entry| has no "etag" or "last-modified" headers.
  * |entry| has a "last-modified" header, but it is not equal to |external_validation_header|'s |last_modified_date|.
  * |entry| has an "etag" header, but it does not match |external_validation_header|'s |etag|.

Let |is_validation_request| be the result of this test.

If |is_validation_request|, then we can safely use the response from the subsequent network response to update |entry|.

If |!is_validation_request|, then we disable caching before proceeding on to the network request.
NOTE: we turned off writing back to cache in this case, since a 304 response received from the server doesn't tell us anything about our cache entry. And moreover trying to handle a non-304 response would be awkward to deal with since the transaction would have to enter a "maybe will write to cache" state.

(5)

Start the network transaction.

(6)
   
On completion of the network transaction:

if we are doing an internal OR an external validation request:
 if |http_code == 304|
   update |entry|'s response headers with the new response headers.
   if it was externally conditionalized:
     return the received response (304) to the user
   else if it was internally conditionalized:
     return the cached response (200) to the user


Review URL: http://codereview.chromium.org/159463

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22328 0039d316-1c4b-4281-b951-d872f2087c98

0 files changed, 0 insertions, 0 deletions