Re: Requiring proxies to process warn-date

Alex Rousskov <> Wed, 15 May 2013 23:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 51AE911E80BA for <>; Wed, 15 May 2013 16:03:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cY3mB6uxuQVp for <>; Wed, 15 May 2013 16:03:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 181A721F84CD for <>; Wed, 15 May 2013 16:03:31 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UckiC-0003UK-T9 for; Wed, 15 May 2013 23:02:20 +0000
Resent-Date: Wed, 15 May 2013 23:02:20 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1Ucki0-0003Tb-89 for; Wed, 15 May 2013 23:02:08 +0000
Received: from ([]) by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <>) id 1Uckhv-0001od-Ka for; Wed, 15 May 2013 23:02:08 +0000
Received: from [] (localhost []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id r4FN1fPp004401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <>; Wed, 15 May 2013 17:01:41 -0600 (MDT) (envelope-from
Message-ID: <>
Date: Wed, 15 May 2013 17:01:35 -0600
From: Alex Rousskov <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: " Group" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.8
X-W3C-Hub-Spam-Report: AWL=-3.134, RP_MATCHES_RCVD=-0.629, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1Uckhv-0001od-Ka e17e67febd59c7cea8ff5f1c21e7aa4d
Subject: Re: Requiring proxies to process warn-date
Archived-At: <>
X-Mailing-List: <> archive/latest/18013
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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 :-).