W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

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

From: Mark Nottingham <mnot@mnot.net>
Date: Sat, 19 Sep 2009 18:47:40 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <5E34B4E4-2134-470F-B526-872AEF6D805C@mnot.net>
To: Henrik Nordstrom <henrik@henriknordstrom.net>

On 18/09/2009, at 8:55 AM, Henrik Nordstrom wrote:

> tor 2009-09-17 klockan 12:03 +1000 skrev Mark Nottingham:
>> 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.
> Does it?

Many implementations do, yes.

> 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
>> lists as
>> well, or
> I think only no-store is relevant there.. Expiration and  
> revalidation is
> as specified not relevant to history lists.


>>  2. Some other history-specific directives need to be minted (out of
>> scope
>> for HTTPbis, but it can be discussed on-list)
> 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.

> 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.

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

Mark Nottingham     http://www.mnot.net/
Received on Monday, 21 September 2009 01:37:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:51 UTC