[Bug 7689] Cache-defeating semantics are not defined

http://www.w3.org/Bugs/Public/show_bug.cgi?id=7689


Nikunj Mehta <nikunj.mehta@oracle.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|NEEDSINFO                   |




--- Comment #6 from Nikunj Mehta <nikunj.mehta@oracle.com>  2009-09-30 16:39:58 ---
(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.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 30 September 2009 16:40:00 UTC