Bug 16408 - back/forward HTTP navigations fail to prefer loading from cache
Summary: back/forward HTTP navigations fail to prefer loading from cache
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC All
: P2 Major
Assignee: Darin Fisher (:fishd, Google)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-12-11 23:33 PST by Darin Fisher (:fishd, Google)
Modified: 2007-12-12 14:37 PST (History)
0 users

See Also:

Attachments
patch: reverse sense (1.21 KB, patch)
2007-12-11 23:57 PST, Darin Fisher (:fishd, Google) 		mjs: review+
Details | Formatted Diff | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Darin Fisher (:fishd, Google) 2007-12-11 23:33:17 PST 
back/forward HTTP navigations fail to prefer loading from cache

HTTPS navigations however are aggressively served from cache on back/forward.  it seems like the behavior of HTTP and HTTPS on back/forward is reversed from what it should be.

here's the code that seems wrong:

  case FrameLoadTypeIndexedBackForward:
      if (itemURL.protocol() == "https")
          request.setCachePolicy(ReturnCacheDataElseLoad);
      break;

this code is in FrameLoader::loadItem

i believe that the sense of that comparison should be reversed.
Comment 1 Darin Fisher (:fishd, Google) 2007-12-11 23:57:41 PST 
Created attachment 17860 [details]
patch: reverse sense
Comment 2 Maciej Stachowiak 2007-12-12 04:53:34 PST 
Comment on attachment 17860 [details]
patch: reverse sense

r=me
Comment 3 Oliver Hunt 2007-12-12 14:37:59 PST 
Landed r28662