Subject: #197: Effect of CC directives on history lists

From: Mark Nottingham <[email-masked]>
Date: Thu, 17 Sep 2009 12:03:25 +1000

#197: Effect of CC directives on history lists
-------------------------------- 
+-------------------------------------------
Reporter:  [email-masked]      |       Owner:
     Type:  design              |      Status:  new
Priority:  normal              |   Milestone:  unassigned
Component:  p6-cache            |     Version:  00-draft
Severity:  Active WG Document  |    Keywords:
   Origin:                      |
-------------------------------- 
+-------------------------------------------
Several browser vendors do or will soon respect CC: no-store and CC:  
max-
age=0, must-revalidate for the purposes of history lists, because they  
see
storing some responses in the history list as a security concern (e.g.,
something with credit card numbers on it).

However, 2616 says that a cache and a history list are separate, and  
notes
that history lists should not unnecessarily prevent users from viewing
stale resources.

This is vague; the wording here implies that the history list has the  
same
store as the cache, even though they are almost always implemented
separately, as the history list needs to incorporate browser-side  
state as
well as resource state.

This section needs to be revised, and furthermore some means of control
over the history list needs to be provided; either

  1. CC: no-store (and possibly other) directives apply to history  
lists as
well, or
  2. Some other history-specific directives need to be minted (out of  
scope
for HTTPbis, but it can be discussed on-list)

See also:
   https://bugs.webkit.org/show_bug.cgi?id=26777
   https://bugzilla.mozilla.org/show_bug.cgi?id=441751#c58
   http://blogs.imeta.co.uk/JDeabill/archive/2008/07/14/303.aspx

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/197>
httpbis <http://tools.ietf.org/wg/httpbis/>

--
Mark Nottingham     http://www.mnot.net/

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 18 Sep 2009 00:55:17 +0200

> separately, as the history list needs to incorporate browser-side  

Does it?

Are we talking about the note at the end of 13.13? To me that note is
there to explain why history list SHOULD NOT be the same as cache...

>   1. CC: no-store (and possibly other) directives apply to history  

I think only no-store is relevant there.. Expiration and revalidation is
as specified not relevant to history lists. 

> for HTTPbis, but it can be discussed on-list)

no-store should be quite sufficient imho.

respecting max-age=0 in history lists would be very annoying, and
inconsistent if handled very much different from max-age=1.

but on the other hand most browsers do not implement history lists
exactly as specified, but instead do load much content from cache when
navigating the history and often even respect expiration.

Regards
Henrik

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 19 Sep 2009 18:47:40 +1000

>> separately, as the history list needs to incorporate browser-side

Many implementations do, yes.

> there to explain why history list SHOULD NOT be the same as cache...

yes.

> as specified not relevant to history lists.

yes

> no-store should be quite sufficient imho.

I'm inclined to agree, although AIUI some of the browser vendors are  
also paying attention to various combinations of no-cache / must- 
revalidate / max-age=0. It would be good if we could engage with them  
to discuss.

> inconsistent if handled very much different from max-age=1.

agreed

> navigating the history and often even respect expiration.

To some degree, yes, but that doesn't prevent us from trying to  
improve the situation.

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 21 Sep 2009 13:09:51 +0200

> Many implementations do, yes.

I meant the first part "the wording here implies..."

> revalidate / max-age=0. It would be good if we could engage with them  

Agreed. But I vote that we focus on no-store for the spec writing for
now, until browser vendors give good arguments what is wrong with that.

But this part of the specifications should only be advisory and best
practice recommendation, giving browsers permission to bypass freshness
controls on accesses due to history navigation, not a strict requirement
on implementaitons to do exactly this.

> > inconsistent if handled very much different from max-age=1.

Is there something missing in the existing wording on why expiration
preferably should not be respected in history navigation?

Regards
Henrik

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 21 Sep 2009 10:05:25 -0500

Henrik Nordstrom wrote:
> controls on accesses due to history navigation, not a strict
> requirement on implementaitons to do exactly this.

Why does the HTTP specification even need to mention history lists. The vast majority of HTTP caches do not even maintain history lists. The ones that do (built into browsers) will design their history list mechanism according to their own security & performance goals. Plus, as Henrik noted previously, there's a lot more to a browser history list than caching the HTTP request/response (ActiveX/plugin state, Javascript state, SVG animation state, Javascript APIs for controlling history, etc.)

Regards,
Brian

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 21 Sep 2009 20:49:43 +0200

mån 2009-09-21 klockan 10:05 -0500 skrev Brian Smith:
> Why does the HTTP specification even need to mention history lists.
> The vast majority of HTTP caches do not even maintain history lists.
> The ones that do (built into browsers) will design their history list
> mechanism according to their own security & performance goals. Plus,
> as Henrik noted previously, there's a lot more to a browser history
> list than caching the HTTP request/response (ActiveX/plugin state,
> Javascript state, SVG animation state, Javascript APIs for controlling
> history, etc.)

It's an explicit freedom to disregard HTTP freshness controls in history
buffers and the like.

But yes, the fine details there belongs more in a browser profile
specification than the HTTP specifications as such.

Regards
Henrik

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 22 Sep 2009 11:55:36 +1000

As the spec mentioned, it's relevant to HTTP because people often  
misinterpret the relationship between a cache and a history list, and  
mis-implementation of a history list can incent people to avoid caching.

At this point it sounds like we want to refine the language to more  
explicitly point out that expiration mechanisms don't apply to history  
lists, but other cache-control directives may (e.g., no-store). I also  
hear some reluctance to go further than this, because if we did we'd  
need to more fully specify history lists.

On 22/09/2009, at 1:05 AM, Brian Smith wrote:

> The ones that do (built into browsers) will design their history  
> list mechanism according to their own security & performance goals.  
> Plus, as Henrik noted previously, there's a lot more to a browser  
> history list than caching the HTTP request/response (ActiveX/plugin  
> state, Javascript state, SVG animation state, Javascript APIs for  
> controlling history, etc.)
>
> Regards,
> Brian
>
>