Here are some areas that seem to be common pitfalls. Comments/additions
welcome; this is just a starting point.
* obeying server-side freshness controls (all Cache-Control, Expires)
* proper generation of Age headers
* handling of Date headers
* caching negotiated responses (Vary header)
* parsing combined ("folded") HTTP headers
* byte-range handling
* erroneous forwarding of hop-by-hop headers
* invalidation of cache entries (upon POST, etc)
While there are many other compliance issues, I've selected these because
they effect cachability, an areas that IMHO vendors have a conflict of
interest about, to some degree. It's very much in the interest of vendors to
assure that a device operates correctly in the eyes of the ISP (thier
customer), but that may not be the case for the HTTP mechanisms which
represent the origin server's wishes.
Two issues present themselves:
* HTTP Version
More caches are presenting themselves as HTTP/1.1 devices, which makes it
easy to know what criteria to apply to them, but several still advertise as
1.0 devices. However, they do use 1.1 mechanisms. This is further confused
by the differences between RFC2068 and RFC2616.
* Nature of tests
I think this was discussed before, but there are different kinds of
behaviours that we can look for; some that are necessary for compliance
(required), and some that are a Good Idea (optimal). While there will
undoubtedly be different perceptions of what optimal is, I think we can and
should test for some 'safe' optimal behaviours, especially in terms of
taking advantage of the cacheability of an object.
-- Mark Nottingham, Senior Developer Akamai Technologies (San Mateo, CA)
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:28 MST