Subject: Requiring proxies to process warn-date

From: Mark Nottingham <[email-masked]>
Date: Wed, 8 May 2013 23:14:09 +1000

In #480, Alex brought this text up in p6:

> 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.
> 
> If a system receives a message with a warning-value that includes a warn-date, and that warn-date is different from the Date value in the response, then that warning-value must be deleted from the message before storing, forwarding, or using it. (preventing the consequences of naive caching of Warning header fields.) If all of the warning-values are deleted for this reason, the Warning header field must be deleted as well.

My inclination here is to change the first paragraph to begin "If a sender generates a message...", and the second to be "If a recipient receives...", also removing "forwarding" later down.

This is because IME proxies do not do any of this for messages that they aren't caching, and moreover there are whole classes of implementations that won't.

Thoughts?

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

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 15 May 2013 17:01:35 -0600

>> 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.

>> If a system receives a message with a warning-value that includes a
>> warn-date, and that warn-date is different from the Date value in
>> the response, then that warning-value must be deleted from the
>> message before storing, forwarding, or using it. (preventing the
>> consequences of naive caching of Warning header fields.) If all of
>> the warning-values are deleted for this reason, the Warning header
>> field must be deleted as well.

> My inclination here is to change the first paragraph to begin "If a
> sender generates a message...",

This would address my concern about the first paragraph, thank you.

> 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)?

> This is because IME proxies do not do any of this for messages that
> they aren't caching, and moreover there are whole classes of
> implementations that won't.

You can also look at this from a different view point: Should every hop
suffer implementing this MUST just to protect some "naive caches" down
the road? Seems like the onus should be on those naive caches, 99.9% of
which do not even know about Warning headers :-).

Cheers,

Alex.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 17 May 2013 11:40:31 +1000

> storing, only in serving from the cache)?

I think so, although we should remove the first 'response'.

> which do not even know about Warning headers :-).

Agreed.

This is a non-editorial change, so I'm giving it a new issue number:
  http://trac.tools.ietf.org/wg/httpbis/trac/ticket/486

I think the path outlined above is a good resolution; if anyone has concerns, please say so.

Regards,

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 20 May 2013 11:36:02 +1000

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?

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 20 May 2013 10:14:32 -0600

> 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.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 28 May 2013 15:36:24 +1000

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,

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 29 May 2013 16:43:18 +1000

OK, I've marked this for incorporation; see <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/486#comment:3> for latest text.