- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 3 Sep 2013 16:14:55 +1000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
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. Cheers, -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 3 September 2013 06:15:24 UTC