- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 21 Jan 2010 10:02:33 +1100
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, Henrik Nordstrom <henrik@henriknordstrom.net>, Brian Smith <brian@briansmith.org>
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
>> 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
--
Mark Nottingham http://www.mnot.net/
Received on Wednesday, 20 January 2010 23:03:06 UTC