Opened 6 years ago

Closed 6 years ago

#486 closed design (fixed)

Requiring proxies to process warn-date

Reported by: mnot@… Owned by: mnot@…
Priority: normal Milestone: 24
Component: p6-cache Severity: In WG Last Call
Keywords: Cc:

Description

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.

Attachments (1)

486.diff (4.1 KB) - added by julian.reschke@… 6 years ago.
Proposed patch

Download all attachments as: .zip

Change History (17)

comment:1 Changed 6 years ago by fielding@…

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

comment:2 Changed 6 years ago by 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.

comment:3 Changed 6 years ago by mnot@…

  • Milestone changed from unassigned to 23

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.

comment:4 Changed 6 years ago by 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).

comment:5 Changed 6 years ago by mnot@…

Need to take it to the list, then.

comment:6 Changed 6 years ago by mnot@…

  • Milestone changed from 23 to unassigned

comment:7 Changed 6 years ago by mnot@…

  • Owner changed from draft-ietf-httpbis-p6-cache@… to mnot@…

Changed 6 years ago by julian.reschke@…

Proposed patch

comment:8 Changed 6 years ago by julian.reschke@…

From [2368]:

tune warn-date requirements (see #486)

comment:9 Changed 6 years ago by julian.reschke@…

  • Milestone changed from unassigned to 24
  • Resolution set to incorporated
  • Status changed from new to closed

comment:10 Changed 6 years ago by fielding@…

  • Resolution incorporated deleted
  • Status changed from closed to reopened

Almost there ...

comment:11 Changed 6 years ago by fielding@…

From [2382]:

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

comment:12 Changed 6 years ago by 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

comment:13 Changed 6 years ago by fielding@…

  • Resolution set to incorporated
  • Status changed from reopened to closed

comment:14 Changed 6 years ago by julian.reschke@…

From [2385]:

Note changes for [2384] (see #486)

comment:15 Changed 6 years ago by mnot@…

  • Resolution incorporated deleted
  • Status changed from closed to reopened

comment:16 Changed 6 years ago by mnot@…

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.