Re: #486: Requiring proxies to process warn-date

Anyone have strong feelings about this? 

Personally - it seems reasonable to me to shift the overhead for assuring Warning correctness to those consuming it, since practically, they need to anyway today (as intermediaries don't implement this at all, IME).

Cheers,



On 21/05/2013, at 2:14 AM, Alex Rousskov <rousskov@measurement-factory.com> wrote:

> On 05/19/2013 07:36 PM, Mark Nottingham wrote:
>> On 17/05/2013, at 11:40 AM, Mark Nottingham <mnot@mnot.net> wrote:
>> 
>>>>> 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'.
> 
>> Looking at this again:
> 
>>> A cache MUST NOT send a warning-value with a warn-date different from the Date value in the from-cache response.
> 
> 
>> This has the effect of requiring caches to check warning-values in
>> all cached responses; do we still want to require that?
> 
> 
> Good question. I do not know what the use cases behind the original
> MUSTs were, and whether new use cases appeared since then, so I cannot
> answer this question. If there is consensus that policing Warnings by
> intermediaries (including caches) is not needed, then yes, we can remove
> the entire MUST NOT.
> 
> 
> Cheers,
> 
> Alex.
> 
> 

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

Received on Tuesday, 28 May 2013 05:36:52 UTC