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

On 2013-09-03 08:14, Mark Nottingham wrote:
>
> On 03/09/2013, at 4:12 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
>
>> On 2013-09-03 02:37, Mark Nottingham wrote:
>>>
>>> On 02/09/2013, at 11:04 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
>>>
>>>> 3) RFC 2616 has in <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.46.p.19>:
>>>>
>>>> "If an implementation sends a message with one or more Warning headers whose version is HTTP/1.0 or lower, then the sender MUST include in each warning-value a warn-date that matches the date in the response."
>>>>
>>>> HTTPbis changed this to:
>>>>
>>>> "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."
>>>>
>>>> Was that an intentional change at all?
>>>
>>> Yes; Warning headers don't have a version, so clearly the intent was for the condition to be upon the recipient.
>>
>> But the message they appear in has. I'm not a caching expert, but while reviewing the history I got the expression that we are trying to "fix" something that we broken ourselves. It would be good to understand what the intent of the text in 2616 was.
>
> 2616 defines what it means to send HTTP/1.1 messages, not 1.0. Besides which, what the sending implementation / message version is has nothing to do with the intent of including the date, which is to make sure that *intervening* 1.0 caches don't cause the Warning to be persisted longer than it's valid for.

Yes. But I'm still trying to understand the history.

RFC 2616 was the first spec to define "Warning" -- what is the backwards 
compat story here? After all, an 1.0 intermediary will not even know 
what "Warning" is.

What am I missing here?

Best regards, Julian

Received on Tuesday, 3 September 2013 06:46:38 UTC