#486: Requiring proxies to process warn-date

On 16/05/2013, at 9:01 AM, Alex Rousskov <rousskov@measurement-factory.com> wrote:

> 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)?

I think so, although we should remove the first 'response'.


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

Agreed.

This is a non-editorial change, so I'm giving it a new issue number:
  http://trac.tools.ietf.org/wg/httpbis/trac/ticket/486

I think the path outlined above is a good resolution; if anyone has concerns, please say so.

Regards,

--
Mark Nottingham   http://www.mnot.net/

Received on Friday, 17 May 2013 01:41:00 UTC