Requiring proxies to process warn-date

[mnot@…]

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.

[fielding@…]

The requirement is irrelevant anyway since nobody processes Warning header fields. Let's just remove the requirement.

[mnot@…]

I don't think we can do that, at least without a pretty extensive discussion. There was signficant pushback against getting rid of requirements around Warning altogether a while back, and I don't think that's changed.

This proposal effectively limits the requirements' application to those who actually use the Warning, so it has much the same effect -- i.e., if you don't care about Warning, you don't have to deal with it.

[mnot@…]

Change:

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.

to begin:

If a sender generates a message...

Change:

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.

to:

A sender MUST NOT generate warning-value with a warn-date different from the Date value in the response. A recipient MUST ignore a warning-value with a warn-date different from the Date value in the response.

[fielding@…]

I disagree that we need to preserve these requirements. We should deprecate warn-date and remove the requirements because the parsing algorithm for finding that date is expensive (a date that nobody sends, as far as I can tell).

[mnot@…]

Need to take it to the list, then.

[julian.reschke@…]

Proposed patch

[julian.reschke@…]

From [2368]:

tune warn-date requirements (see #486)

[fielding@…]

Almost there ...

[fielding@…]

From [2382]:

Revert [2368] that attempted to address #486 because it adds incompatible requirements to HTTP/1.1 senders of Warning

[fielding@…]

From [2384]:

Reduce the burden of processing warn-date to recipients that do something with Warning fields; use warn-code section titles to demonstrate syntax examples (and differentiate from status codes); clarify tortured wording around Age; demonstrate 4am mastery of xslt; addresses #486

[julian.reschke@…]

From [2385]:

Note changes for [2384] (see #486)