[Webkit-unassigned] [Bug 49672] New: Allow no-store resources to be used for back navigation

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=49672

           Summary: Allow no-store resources to be used for back
                    navigation
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Mac OS X 10.5
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Page Loading
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: joepeck at webkit.org


The HTTP spec allows 'Cache-Control: no-store' resources to be used when used for "History", such as back/forward navigation.

Relevant parts of the spec:
http://www.ietf.org/rfc/rfc2616.txt

13.13 History Lists

    User agents often have history mechanisms, such as "Back" buttons
    and history lists, which can be used to redisplay an entity retrieved
    earlier in a session.

>   History mechanisms and caches are different. In particular history
>   mechanisms SHOULD NOT try to show a semantically transparent view
>   of the current state of a resource. Rather, a history mechanism is
>   meant to show exactly what the user saw at the time when the resource
>   was retrieved.

    By default, an expiration time does not apply to history mechanisms.
    If the entity is still in storage, a history mechanism SHOULD display
    it even if the entity has expired, unless the user has specifically
    configured the agent to refresh expired history documents.

    This is not to be construed to prohibit the history mechanism from
    telling the user that a view might be stale.


14.9.2 What May be Stored by Caches

   no-store
      The purpose of the no-store directive is to prevent the
      inadvertent release or retention of sensitive information (for
      example, on backup tapes). The no-store directive applies to the
      entire message, and MAY be sent either in a response or in a
      request. If sent in a request, a cache MUST NOT store any part of
      either this request or any response to it. If sent in a response,
      a cache MUST NOT store any part of either this response or the
      request that elicited it. This directive applies to both non-
      shared and shared caches. "MUST NOT store" in this context means
      that the cache MUST NOT intentionally store the information in
      non-volatile storage, and MUST make a best-effort attempt to
      remove the information from volatile storage as promptly as
      possible after forwarding it.

>     Even when this directive is associated with a response, users
>     might explicitly store such a response outside of the caching
>     system (e.g., with a "Save As" dialog). History buffers MAY store
>     such responses as part of their normal operation.

      The purpose of this directive is to meet the stated requirements
      of certain users and service authors who are concerned about
      accidental releases of information via unanticipated accesses to
      cache data structures. While the use of this directive might
      improve privacy in some cases, we caution that it is NOT in any
      way a reliable or sufficient mechanism for ensuring privacy. In
      particular, malicious or compromised caches might not recognize or
      obey this directive, and communications networks might be
      vulnerable to eavesdropping.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.