This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 7689 - Cache-defeating semantics are not defined
Summary: Cache-defeating semantics are not defined
Status: VERIFIED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://dev.w3.org/html5/spec/Overview...
Whiteboard:
Keywords: NE, NoReply
Depends on:
Blocks:
 
Reported: 2009-09-21 17:21 UTC by Nikunj Mehta
Modified: 2010-10-04 14:47 UTC (History)
4 users (show)

See Also:


Attachments

Description Nikunj Mehta 2009-09-21 17:21:11 UTC
[[
Attempts to fetch resources as part of the application cache update process may be done with cache-defeating semantics, to avoid problems with stale or inconsistent intermediary caches.
]]

What are these cache-defeating semantics? Where are they defined?
Comment 1 Ian 'Hixie' Hickson 2009-09-29 07:55:39 UTC
The spec doesn't define exactly how aggressive a user agent should be, since it typically depends on the user preferences, the protocol, the bandwidth availability, the time since the last update, the presence of proxies and remote caches, and many other factors.
Comment 2 Nikunj Mehta 2009-09-29 16:26:50 UTC
Presently the contentious text appears in normative language. If cache-defeating semantics are non-normative techniques, then this paragraph should be made into a note.
Comment 3 Ian 'Hixie' Hickson 2009-09-29 22:37:56 UTC
They're normative, in that implementations MAY defeat caches to whatever extent they desire, but there's no precise set of rules given for how they should do that.

Making it non-normative would mean that implementors could no longer do this, so that doesn't work.

Do you have any other proposal for how to address this? I don't really know how to address your feedback here.
Comment 4 Nikunj Mehta 2009-09-29 23:22:30 UTC
It necessary to be clear about HTTP and HTML requirements around caching.

From step 7.2 of Section 6.9.4, a non-normative note says
[[
HTTP caching rules, such as Cache-Control: no-store, are ignored for the purposes of the application cache update process.
]]

This contradiction suggests to me that all cache-related semantics need to be specified to the same level of rigor. 

My proposal is to either be specific in a normative manner about the kinds of cache semantics that must be ignored or may be permitted. The specific semantics that are actually applied are then bounded in this range.
Comment 5 Ian 'Hixie' Hickson 2009-09-30 07:27:40 UTC
> From step 7.2 of Section 6.9.4, a non-normative note says
> [[
> HTTP caching rules, such as Cache-Control: no-store, are ignored for the
> purposes of the application cache update process.
> ]]
> 
> This contradiction suggests to me that all cache-related semantics need to be
> specified to the same level of rigor. 

This isn't a contradiction; it's a description of what the algorithm already does. That is, the algorithm caches data from the server regardless of the Cache-Control headers _from_ the server.

The bit you quoted at the very top of this bug is about user agents sending cache-related headers _to_ the server, which is completely unrelated.


> My proposal is to either be specific in a normative manner about the kinds of
> cache semantics that must be ignored or may be permitted. The specific
> semantics that are actually applied are then bounded in this range.

Do you have any suggestions for what should _not_ be permitted? I don't really understand what this would look like.
Comment 6 Nikunj Mehta 2009-09-30 16:39:58 UTC
(In reply to comment #5)
> > From step 7.2 of Section 6.9.4, a non-normative note says
> > [[
> > HTTP caching rules, such as Cache-Control: no-store, are ignored for the
> > purposes of the application cache update process.
> > ]]
> > 
> > This contradiction suggests to me that all cache-related semantics need to be
> > specified to the same level of rigor. 
> 
> This isn't a contradiction; it's a description of what the algorithm already
> does. That is, the algorithm caches data from the server regardless of the
> Cache-Control headers _from_ the server.
> 

The contradiction is that a description of what the algorithm does is in non-normative text.

> The bit you quoted at the very top of this bug is about user agents sending
> cache-related headers _to_ the server, which is completely unrelated.
> 

My point is that the spec is inconsistent in its approach towards cache semantics.

> 
> > My proposal is to either be specific in a normative manner about the kinds of
> > cache semantics that must be ignored or may be permitted. The specific
> > semantics that are actually applied are then bounded in this range.
> 
> Do you have any suggestions for what should _not_ be permitted? I don't really
> understand what this would look like.
> 

Cache defeating semantics are identified here - http://www.basswood.com/standards/WD-countmethod.html. Identifying the techniques that are permitted should be either good enough or leaving out the whole discussion on cache-defeating semantics should be fine. THe current situation doesn't really help anyone.

Comment 7 Ian 'Hixie' Hickson 2009-10-18 10:01:55 UTC
> The contradiction is that a description of what the algorithm does is in
> non-normative text.

Why is that a contradiction? Non-normative text often explains the implications of normative text.


> > The bit you quoted at the very top of this bug is about user agents sending
> > cache-related headers _to_ the server, which is completely unrelated.
> 
> My point is that the spec is inconsistent in its approach towards cache
> semantics.

Consistency is not necessarily a goal (though it's nice in general). In this case, it seems the inconsistency, such as it is, is warranted by the different and asymmetric needs of server-side and client-side requirements.


> > > My proposal is to either be specific in a normative manner about the kinds of
> > > cache semantics that must be ignored or may be permitted. The specific
> > > semantics that are actually applied are then bounded in this range.
> > 
> > Do you have any suggestions for what should _not_ be permitted? I don't really
> > understand what this would look like.
>
> Cache defeating semantics are identified here -
> http://www.basswood.com/standards/WD-countmethod.html. Identifying the
> techniques that are permitted should be either good enough or leaving out the
> whole discussion on cache-defeating semantics should be fine. The current
> situation doesn't really help anyone.

That doesn't really answer my question.

There's no point listing which features are permitted if all of them are permitted. Which should _not_ be permitted?
Comment 8 Nikunj Mehta 2009-10-19 18:11:23 UTC
(In reply to comment #7)
> > > > My proposal is to either be specific in a normative manner about the kinds of
> > > > cache semantics that must be ignored or may be permitted. The specific
> > > > semantics that are actually applied are then bounded in this range.
> > > 
> > > Do you have any suggestions for what should _not_ be permitted? I don't really
> > > understand what this would look like.
> >
> > Cache defeating semantics are identified here -
> > http://www.basswood.com/standards/WD-countmethod.html. Identifying the
> > techniques that are permitted should be either good enough or leaving out the
> > whole discussion on cache-defeating semantics should be fine. The current
> > situation doesn't really help anyone.
> 
> That doesn't really answer my question.
> 
> There's no point listing which features are permitted if all of them are
> permitted. Which should _not_ be permitted?
> 

My proposal is not to identify what is not permitted, but simply to move the statement on cache-defeating semantics to a note.
Comment 9 Ian 'Hixie' Hickson 2009-10-20 00:47:44 UTC
If we made it a note, then UAs wouldn't be allowed to use cache-defeating semantics, since there'd be no normative statement allowing it.
Comment 10 Maciej Stachowiak 2010-03-14 14:51:33 UTC
This bug predates the HTML Working Group Decision Policy.

If you are satisfied with the resolution of this bug, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
  http://dev.w3.org/html5/decision-policy/decision-policy.html

This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.