Bug 15121
| Summary: | REGRESSION (r18541): Refreshing a cached https page does not reload CSS and JavaScript resources | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Jim Studt <jim> |
| Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | beidson, mrowe |
| Priority: | P1 | Keywords: | HasReduction, InRadar, Regression |
| Version: | 523.x (Safari 3) | ||
| Hardware: | Mac | ||
| OS: | OS X 10.4 | ||
| URL: | https://core.federated.com/~jim/webkitbug/ | ||
Jim Studt
If you return to an SSL accessed page with Javascript or CSS files linked using 'back', then pressing 'Reload' or 'Shift+Reload' will only get the main file, not the Javascript or CSS files. The problem does not present if using HTTP to access the same pages and is not present in the webkit version shipped with 10.4.10.
Needless to say this will drive you mad when editing CSS and Javascript files over SSL.
Setting expire times in the past or cache control to no cache on the CSS and Javascript files does not effect the problem.
The problem presents from at least Apache 2.2 and lighttpd. I have not tested other servers.
You can see the problem at https://core.federated.com/~jim/webkitbug/ and see it not be a problem at http://core.federated.com/~jim/webkitbug/ There are navigation instructions on those pages, but it is simply going forward a page, back, refreshing, and comparing the two times at the top of the file, one of which is set when the page is fetched, and the other when the associated javascript file is fetched.
The three files in that directory can be retrieved from http://core.federated.com/~jim/webkitbug/webkitbug.tar.gz
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Mark Rowe (bdash)
The HTTP caching is implemented at a level below WebKit, so this bug will need to be migrated to Radar if it is confirmed. I cannot reproduce the behaviour that you describe.
Oliver Hunt
This is a *webkit* issue. Hitting the refresh button doesn't refresh all cached resources, hitting enter in the url bar does.
So visiting the page, following the link, waiting, hitting back, and then hitting enter in the url bar does a correct refresh, whereas just using the reload button does not.
Mark Rowe (bdash)
Oliver, I don't think the problem is what you think it is. The case you're thinking of affects HTTP as well as HTTPS sites. Signs point to this being outside of WebKit as I can reproduce this in 10.4 with the most recent nightly build, but not on 10.5. However, as the reporter mentions, it does not reproduce with Safari 2.0.x. That makes things a bit more confusing. I guess we need a little more investigation to see what is happening on reload that causes this to not work correctly.
David Kilzer (:ddkilzer)
I can confirm this is a regression from shipping Safari 2.0.4 (419.3) with original WebKit on Mac OS X 10.4.10 (8R218).
Jim Studt
I checked the test cases, and webkit does not exhibit this problem if I cause the reload by pressing enter in the url bar, but it does if I press the reload button or shift-reload.
David Kilzer (:ddkilzer)
The autospade script confirms that this regression occurred in Big Back/Forward Cache Rewrite of r18541:
Works: r18540 Fails: r18541
David Kilzer (:ddkilzer)
<rdar://problem/5453350>
Adele Peterson
Committed revision 25779.