W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2007

Warning and Date

From: Travis Snoozy (Volt) <a-travis@microsoft.com>
Date: Mon, 8 Jan 2007 10:54:37 -0800
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <86EDC3963F04D546BED8996F77D290F6049D118420@NA-EXMSG-C138.redmond.corp.microsoft.com>

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.


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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:41 UTC