Bug 34969 – [chromium] expose cache-bypass flag in reload() API

• Component: New Bugs
• Status: RESOLVED FIXED

[Evan Martin]

[chromium] expose endToEnd flag in reload() API

[Evan Martin]

Created attachment 48794 [details]
Patch

[Evan Martin]

This patch requires a patch on the Chrome side as well.  Advice welcome on the best way to land it.

[Evan Martin]

Chrome-side change: http://codereview.chromium.org/605026/show

[Darin Fisher (:fishd, Google)]

I'm not sure that "end to end" is the right name here.

reload(false) means send Cache-control: max-age=0, which means "end-to-end validation"

reload(true) means send Cache-control: no-cache, which means "end-to-end refetch"

Both cases are end-to-end in other words.  I think the parameter to FrameLoader::reload is similarly misnamed.  This is spelled out in section 14.9.4 of RFC 2616.

[Evan Martin]

Here's the code in FrameLoader:

    if (loadType == FrameLoadTypeReload) {
        request.setCachePolicy(ReloadIgnoringCacheData);
        request.setHTTPHeaderField("Cache-Control", "max-age=0");
    } else if (loadType == FrameLoadTypeReloadFromOrigin) {
        request.setCachePolicy(ReloadIgnoringCacheData);
        request.setHTTPHeaderField("Cache-Control", "no-cache");
        request.setHTTPHeaderField("Pragma", "no-cache");

endToEnd=true causes the second loadtype:
    loadWithDocumentLoader(loader.get(), endToEndReload ? FrameLoadTypeReloadFromOrigin : FrameLoadTypeReload, 0);

You worried about the effects of using ReloadIgnoringCacheData in the the review: "I'm afraid that if it is also setting ReloadIgnoringCacheData
that our disk cache will be evicted even for an otherwise conditional
request" but I don't know enough about this code to know what the effects of it are.


Here's the text of the RFC:

   End-to-end reload
      The request includes a "no-cache" cache-control directive or, for
      compatibility with HTTP/1.0 clients, "Pragma: no-cache". Field
      names MUST NOT be included with the no-cache directive in a
      request. The server MUST NOT use a cached copy when responding to
      such a request.

   Specific end-to-end revalidation
      The request includes a "max-age=0" cache-control directive, which
      forces each cache along the path to the origin server to
      revalidate its own entry, if any, with the next cache or server.
      The initial request includes a cache-validating conditional with
      the client's current validator.

Because "end to end reload" is the wording used in the RFC, I can see where the WebKit name came from.  But I agree that it is very confusing.

From your other mails I saw these suggestions:
  LOAD_VALIDATE_CACHE / LOAD_BYPASS_CACHE
  RELOAD_VALIDATING_CACHE / RELOAD_IGNORING_CACHE

I will arbitrarily go with ignoreCache and upload another patch.

[Evan Martin]

Created attachment 48876 [details]
https://bugs.webkit.org/show_bug.cgi?id=34969

[Evan Martin]

Created attachment 48918 [details]
https://bugs.webkit.org/show_bug.cgi?id=34969

[Evan Martin]

Last patch just adds a default arg to reload(), so that this can be rolled into Chrome without needing to synchronize the change Chrome-side.

[Eric Seidel (no email)]

Comment on attachment 48918 [details]
https://bugs.webkit.org/show_bug.cgi?id=34969

OK.  In FrameLoader it appears to be:
    void reload(bool endToEndReload = false);

[Darin Fisher (:fishd, Google)]

r=me too

[WebKit Commit Bot]

Comment on attachment 48918 [details]
https://bugs.webkit.org/show_bug.cgi?id=34969

Clearing flags on attachment: 48918

Committed r54928: <http://trac.webkit.org/changeset/54928>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.