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

From: Henrik Nordstrom <[email-masked]>
Date: Sat, 02 Jan 2010 15:54:28 +0100

Looks fine to me.

Regards
Henrik

tor 2009-12-31 klockan 09:53 +1100 skrev Mark Nottingham:
> Revised proposal:
> 
> """
>  The freshness model [ref] does not necessarily apply to history mechanisms. I.e., 
>   a history mechanism can display a previous representation even if it has expired.
> 
>  This does not prohibit the history mechanism from telling the user that a
>  view might be stale, or from honoring cache directives (e.g., Cache-Control: no-store).
> """
> 
> On 08/10/2009, at 11:37 AM, Mark Nottingham wrote:
> 
> > Existing text:
> > 
> >>  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.
> > 
> > Proposed text:
> > 
> > """
> >  By default, the freshness model [ref] 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, or from honoring cache directives (e.g., Cache-Control: no-store).
> > """
> > 
> > On 22/09/2009, at 4:49 AM, Henrik Nordstrom wrote:
> > 
> >> mån 2009-09-21 klockan 10:05 -0500 skrev Brian Smith:
> >>> Henrik Nordstrom wrote:
> >>>> 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.
> >>> 
> >>> 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
> >> 
> > 
> > 
> > --
> > Mark Nottingham     http://www.mnot.net/
> > 
> > 
> 
> 
> --
> Mark Nottingham     http://www.mnot.net/
>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 06 Jan 2010 16:23:40 +0100

Mark Nottingham wrote:
> ...

Sounds good to me... where should this go? P6, Section 4? Does it 
replace text over there or does it just add to it?

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 19 Jan 2010 13:22:17 +1100

The intent was that it replace the third and forth paragraphs there ('existing text'), but looking at it, I think there's a pretty strong argument to 

1) remove the second paragraph, and
2) remove the note

Thoughts? This isn't a small change, but it does align with current practice, is for purposes of security, and doesn't make any currently conformant implementations non-conformant, AFAICT.

On 07/01/2010, at 2:23 AM, Julian Reschke wrote:

> Mark Nottingham wrote:
>> Revised proposal:
>> """
>> The freshness model [ref] does not necessarily apply to history mechanisms. I.e.,   a history mechanism can display a previous representation even if it has expired.
> Sounds good to me... where should this go? P6, Section 4? Does it replace text over there or does it just add to it?
> 
> Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 19 Jan 2010 19:02:01 +0100

> Thoughts? This isn't a small change, but it does align with current practice, is for purposes of security, and doesn't make any currently conformant implementations non-conformant, AFAICT.

This will reduce Section 4 to:

4.  History Lists

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

    The freshness model (Section 2.3) does not necessarily apply to
    history mechanisms.  I.e., a history mechanism can display a previous
    representation even if it has expired.

    This does not prohibit the history mechanism from telling the user
    that a view might be stale, or from honoring cache directives (e.g.,
    Cache-Control: no-store).

(see <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/197/>)

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 21 Jan 2010 10:02:33 +1100

Yes, I think that's where discussion has lead us. I.e., the text in 2616, while still true to some degree, doesn't tell the whole story, and therefore is somewhat misleading (in that history lists aren't caches, but they also *can* honour cache directives, and sometimes it could be argued that they need to). 

As such, we're getting completely out of the history-list-specifying business, and only mentioning them in passing. 

On 20/01/2010, at 5:02 AM, Julian Reschke wrote:

> Mark Nottingham wrote:
>> The intent was that it replace the third and forth paragraphs there ('existing text'), but looking at it, I think there's a pretty strong argument to 1) remove the second paragraph, and
>> 2) remove the note