Subject: HTTP Compliance tests

From: Mark C Nottingham <[email-masked]>
Date: Thu, 22 Jun 2000 16:40:17 -0700

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)

---

From: Andrew Myers <[email-masked]>
Date: Thu, 22 Jun 2000 21:51:36 -0400 (EDT)

I'd like to suggest one more area: content negotiation.  As a random
example of what can go wrong: Some caches will serve up gzip encoded
content to a client that hasn't advertised that it can accept such
content.  There are a number of uglier issues with content negotiation
(hello byte ranges!), but I'd just like to see some tests for the
really basic stuff.

Andy

 > welcome; this is just a starting point.
[...]

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 23 Jun 2000 14:05:05 -0700

I think this would be taken care of by the Vary testing.

Also, it would be nice (maybe I'm dreaming here) to test a history of
products, not just the most recent a vendor has to offer. From the logs I've
looked at, there are a *lot* of old proxies out there.

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 23 Jun 2000 16:12:50 -0600 (MDT)

> looked at, there are a *lot* of old proxies out there.

Mark,

	The above should not be a problem if the development model I am
advocating is accepted: The compliance testing tool is a collection of
tests. To add a test to the tool, one needs to get enough "votes" from
the "interested parties" participating in the tool development. All test
results are kept private. If you are interested in testing old proxies,
there will be nothing preventing you from running those tests. This is
_not_ a competition so one can test any product one has access to.

$0.02,

Alex.