Bug 77538
| Summary: | 302 redirect for resources with cached location caches the redirect | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Elliott Sprehn <esprehn> |
| Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | abarth, ap, beidson, eric, japhet, koivisto, mnot, ruvim.pinka, youennf |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| URL: | http://plus.google.com/ | ||
| Bug Depends on: | |||
| Bug Blocks: | 119641 | ||
Elliott Sprehn
1. Inject a script src="/redirect/302"
2. /redirect/302 redirects and returns no cache headers (no-store, no-cache, expires, etc.)
3. browser requests the Location which is /destination
4 /destination responds with cache headers
Now repeat step 1 and Webkit will skip the request to /redirect/302 and load /destination from the cache which means if you had a button "Add random script" that requested /random/302 Webkit would actually always load the same script instead of a random one.
You can easily see this in Google+. Open the net inspector and click Send Feedback in the bottom left corner (then hit escape) repeatedly. The first time it requests /activate.js which then redirects to a Location that has cache headers. Every subsequent time you click Send Feedback no requests for activate.js are made even though the response for it had explicit no cache headers.
Confirmed in Nightly (r105480), Chrome 18 dev, and shipping Safari 5.1.2 (6534.52.7). Firefox doesn't have this behavior.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Adam Barth
This is likely caused by the MemoryCache not understand cache headers properly for redirects.
Nate Chapin
(In reply to comment #1)
> This is likely caused by the MemoryCache not understand cache headers properly for redirects.
That's right. CachedResource::m_response will only hold the last ResourceResponse in the redirect chain. Even better, CachedResource::m_request will only hold the ResourceRequest at the start of the redirect chain, so if in the future we request the destination script directly, the cache will miss.
First crazy idea to pop into my head:
Maybe on successful completion of a resource load that redirected, we should prime the cache with a new entry that has the final ResourceRequest and ResourceResponse (and therefore the final url), and if there were any cache control headers, aggressively evict the original CachedResource.
Alexey Proskuryakov
CachedRawResource now keeps the redirect chain, and has some trivial logic for checking correctness, but it's nowhere near complete (only checks cacheControlContainsNoStore()). And of course other resource types don't have anything.