Chromium Code Reviews| Index: third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp |
| diff --git a/third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp b/third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp |
| index 1e493de46d724485056e2a6dce127cda6eecf75c..2eb9236cd3e895ae26276521501002182bdcb589 100644 |
| --- a/third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp |
| +++ b/third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp |
| @@ -705,9 +705,16 @@ ResourceFetcher::RevalidationPolicy ResourceFetcher::determineRevalidationPolicy |
| return Reload; |
| // Certain requests (e.g., XHRs) might have manually set headers that require revalidation. |
| - // FIXME: In theory, this should be a Revalidate case. In practice, the MemoryCache revalidation path assumes a whole bunch |
| + // In theory, this should be a Revalidate case. In practice, the MemoryCache revalidation path assumes a whole bunch |
| // of things about how revalidation works that manual headers violate, so punt to Reload instead. |
| - if (request.isConditional()) |
| + // |
| + // Similarly, a request with manually added revalidation headers can lead |
| + // to a 304 response for a request that wasn't flagged as a revalidation |
| + // attempt. Normally, successful revalidation will maintain the original |
| + // response's status code, but for a manual revalidation the response code |
| + // aremains 304. In this case, the Resource likely has insufficient context |
|
hiroshige
2016/09/23 16:00:19
nit: s/aremains/remains/?
Nate Chapin
2016/09/23 20:45:51
Done.
|
| + // to provide a useful revalidation. |
|
hiroshige
2016/09/23 16:00:19
This looks like this condition is only for prevent
hiroshige
2016/09/23 16:00:19
Could you refer to the crbug entry to provide more
Nate Chapin
2016/09/23 20:45:50
Done.
Nate Chapin
2016/09/23 20:45:50
Done.
|
| + if (request.isConditional() || existingResource->response().httpStatusCode() == 304) |
| return Reload; |
| // Don't try to reuse an in-progress async request for a new sync request. |