- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 3 Sep 2013 10:37:52 +1000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
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. > 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. Cheers, -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 3 September 2013 00:38:20 UTC