Warning and Date

To describe this problem, let's start with a hypothetical network appliance:
a clockless HTTP/1.1 proxy that turns all GIFs it sees upside-down (180-
degree rotation). While the example is silly, such an appliance would seem
reasonable to implement without needing a clock (as would appliances with
similar filter functionality).

However, there's a snag. When sending warning-values to an HTTP/1.0 app, an
HTTP/1.1 app MUST ensure all the warning-values have appropriate warn-dates
(14.46, p150).

Now, imagine the following:

OS --response--> NP ----> OP ----> UA

Where OS is an origin server, NP is our network appliance, OP is an HTTP/1.0
proxy, and UA is an HTTP/1.1 user agent. OS and NP are clockless.

Now, the spec says that you need to add a Date header only if you are the
origin server (with a clock), or you are going to cache the response (14.18,
p125). However, if NP modifies the response (without caching anything), it
MUST add a 213 warn-code (14.46, p150), and it MUST use a warn-date since
it's forwarding to an HTTP/1.0 client (14.46, p150). However, NP is
clockless, so it can't reasonably add a warn-date unless a Date is already
present. Since the origin server is clockless, no Date is present.
Therefore, what would appear to be a reasonable application won't actually
fit into the spec.

So, there are three options that I see:

1. I've interpreted something incorrectly (or missed a part).

2. Assume 2xx warn-codes are immune to the warn-date requirement (I have not
   analyzed the repercussions of this).

3. Assume that anything that adds a warn-code MUST also add a Date (if a
   Date is not present). This requires that the appliance have a clock.


Off the cuff, I'd say that (3) is probably the most compatible way to go
(and most similar to the spec as-written). (2) may be better, in that it
would allow the appliance to be clockless, but I haven't looked into the
guts of that yet.


Thoughts?

--
Travis

Received on Monday, 8 January 2007 18:54:50 UTC