W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: Requiring proxies to process warn-date

From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Wed, 15 May 2013 17:01:35 -0600
Message-ID: <519413CF.7010007@measurement-factory.com>
To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On 05/08/2013 07:14 AM, Mark Nottingham wrote:
> In #480, Alex brought this text up in p6:

>> If an implementation sends a message with one or more Warning
>> header fields to a receiver whose version is HTTP/1.0 or lower,
>> then the sender must include in each warning-value a warn-date that
>> matches the Date header field in the message.

>> If a system receives a message with a warning-value that includes a
>> warn-date, and that warn-date is different from the Date value in
>> the response, then that warning-value must be deleted from the
>> message before storing, forwarding, or using it. (preventing the
>> consequences of naive caching of Warning header fields.) If all of
>> the warning-values are deleted for this reason, the Warning header
>> field must be deleted as well.

> My inclination here is to change the first paragraph to begin "If a
> sender generates a message...",

This would address my concern about the first paragraph, thank you.


> and the second to be "If a recipient receives...", also removing
> "forwarding" later down.

This would not be sufficient because "using" may be interpreted to
include "forwarding". How about this:

"A response sender MUST NOT generate warning-value with a warn-date
different from the Date value in the response. A cache MUST NOT send a
warning-value with a warn-date different from the Date value in the
from-cache response. A recipient MUST ignore a warning-value with a
warn-date different from the Date value in the response."

Would that cover all important cases without being too restrictive (like
requiring the cache not to store something when there is no harm in
storing, only in serving from the cache)?


> This is because IME proxies do not do any of this for messages that
> they aren't caching, and moreover there are whole classes of
> implementations that won't.

You can also look at this from a different view point: Should every hop
suffer implementing this MUST just to protect some "naive caches" down
the road? Seems like the onus should be on those naive caches, 99.9% of
which do not even know about Warning headers :-).


Cheers,

Alex.
Received on Wednesday, 15 May 2013 23:02:08 UTC

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