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

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.

>> And what are we trying to achieve here?
>
> Aligning the spec with reality. Currently, the spec places an requirement upon intermediaries to parse and sometimes remove Warning vales based upon their date (also parsing Date), whether or not they implement a cache. This places an unreasonable burden upon them, and doesn't align well with their motivation -- which has led to this requirement not being implemented widely (or at all?).
>
> It's much more reasonable to place the burden upon the party that's actually consuming the Warning. Given the state of implementation, that's what they'd have to do anyway.

Yes, but that's a problem of the text in httpbis, not in 2616, right?

Best regards, Julian

Received on Tuesday, 3 September 2013 06:12:35 UTC