| Summary: | Main resource loaded via 304 response becomes empty if reloaded by user | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Antti Koivisto <koivisto> | ||||
| Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | commit-queue, japhet | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=144416 | ||||||
| Attachments: |
|
||||||
|
Description
Antti Koivisto
2015-04-29 05:11:41 PDT
Created attachment 251953 [details]
patch
Comment on attachment 251953 [details]
patch
I’ve wondered about this kind of thing for years. Part of the general “what do we want to keep when we reload and what needs to start fresh” topic for requests in general. Also related is the scheme for making reloads bypass cache appropriately.
Is this needed anywhere else? Does it only affect main resources? Is there some way to tie it more closely to other ways we have to change the request in a reloading situation?
> Is this needed anywhere else? Does it only affect main resources? Is there
> some way to tie it more closely to other ways we have to change the request
> in a reloading situation?
Main document loading is a rare case where we have a long-lived ResourceRequest not owned by a CachedResource. The refactoring that moved us from entirely special main resource loading to CachedResources based loading (using CachedRawResource) is basically incomplete so we end up with weird special handling.
http/tests/cache/main-resource-304-reload.html fails on Windows: https://webkit-test-results.appspot.com/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=http%2Ftests%2Fcache%2Fmain-resource-304-reload.html Marked it failing on Windows in http://trac.webkit.org/changeset/183573 (like most of the cache test). |