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. |