- From: Henrik Nordstrom <henrik@henriknordstrom.net>
- Date: Mon, 21 Sep 2009 13:09:51 +0200
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
lör 2009-09-19 klockan 18:47 +1000 skrev Mark Nottingham: > 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. I meant the first part "the wording here implies..." > > 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. 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. > > respecting max-age=0 in history lists would be very annoying, and > > inconsistent if handled very much different from max-age=1. > > agreed Is there something missing in the existing wording on why expiration preferably should not be respected in history navigation? Regards Henrik
Received on Monday, 21 September 2009 11:09:46 UTC