Opened 7 years ago

Closed 7 years ago

Last modified 6 years ago

#480 closed editorial (fixed)

MUSTs and other feedback

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

Description

senders MUST NOT send delta-seconds with a value greater than 2147483648.

Please use "MUST NOT generate" instead. The proxies should not be required to police these values.

For a presented request, a cache MUST NOT send a stored response

This is awkward because many caches never actually send stored responses because they add or modify Connection, Transfer-Encoding, and other hop-by-hop headers to/in a store response. Please consider something like "a cache MUST NOT generate a reply using a stored response" instead.

A cache MUST NOT send a stale response

Please use "MUST NOT generate". A cache may still send a stale response by forwarding it. There is already some text implying that later in the section (see below) but that text belongs to a Warning-generation context, so it is better to be explicit here.

the cache can forward it to the requesting client without adding a new Warning

Use MAY instead of "can"?

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.

Please note that the above MUST requirements can be interpreted to apply to all intermediaries, even those that do not support caching. We have received many complaints from non-caching proxy implementors unknowingly violating these MUSTs and having to implement these complex manipulations that are seemingly irrelevant to their products.

You may also want to replace "implementation" and "system" with sender and recipient to use consistent terminology. If these rules are specific to response messages, then using "server" and "client" would be even better.

If the above requirements are only meant for origin server and user agents, and not all senders and recipients, please fix the actors accordingly.

A system receiving this warning MUST NOT take any automated action, besides presenting the warning to the user.

In this case, the "system" is probably the "user agent" since "presenting the warning to the user" is mentioned. Same for 299 "Miscellaneous Persistent Warning".

Please search the whole text for similar "implementation" and "system" terminology "sprawl".

And here is a list of requirements that are missing an explicit actor on which the requirement is placed. Even though it is possible to guess the actor in most cases, these should be easy to rephrase to place the requirement on the intended actor explicitly (e.g., "A cache MUST" instead of "a response MUST"):

the new response MUST NOT be used to update any stored responses.

the no-cache request pragma-directive MUST have the same effect on

caches

warning-value MUST be deleted from the message before storing,

forwarding, or using it

Change History (4)

comment:1 Changed 7 years ago by mnot@…

From [2247]:

Address editorial feedback from Alex; see #480

comment:2 Changed 7 years ago by mnot@…

Remaining text regarding warn-date brought up on-list; may need a separate issue.

comment:3 Changed 7 years ago by mnot@…

  • Resolution set to fixed
  • Status changed from new to closed

Opened #486.

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

  • Milestone changed from unassigned to 23
Note: See TracTickets for help on using tickets.