Opened 6 years ago

Closed 6 years ago

#475 closed design (fixed)

Strengthening SHOULDs

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

Description (last modified by fielding@…)

Reviewing the current specs, I think there are a few cases where we use SHOULD that are important enough for interop and/or security to justify a MUST (in some cases, with a bit more explanation).

P1 --

  • 3.3.2 "A server SHOULD NOT send a Content-Length header field in any 2xx (Successful) response to a CONNECT request (Section 4.3.6 of [Part2])."
  • B "For compatibility with legacy list rules, recipients SHOULD accept empty list elements." (note that this requirement is in an appendix; it might be good to move it up)

P2 --

  • 4.3.4 "An origin server SHOULD reject any PUT request that contains a Content-Range header field"
  • 4.3.6 "A server SHOULD NOT send any Transfer-Encoding or Content-Length header fields in a successful response." (CONNECT)
  • 4.3.6 "Proxies that support CONNECT SHOULD restrict its use to a limited set of known ports or a configurable whitelist of safe request targets."
  • 5.5.2 "A user agent SHOULD NOT send a Referer header field in an unsecured HTTP request if the referring page was received with a secure protocol."
  • 7.1.1.1 "Recipients of a timestamp value in rfc850-date format, which uses a two-digit year, SHOULD interpret a timestamp that appears to be more than 50 years in the future as representing the most recent year in the past that had the same last two digits."
  • 7.1.2 "When Location is provided in a 3xx (Redirection) response and the URI reference that the user agent used to generate the request target contains a fragment identifier, the user agent SHOULD process the redirection as if the Location field value inherits the original fragment. In other words, if the Location does not have a fragment component, the user agent SHOULD interpret the Location reference as if it had the original reference's fragment." (note repeated requirement; second instance change to "can")

P6 --

  • 4.1.3 "Cache recipients SHOULD consider a date with a zone abbreviation other than "GMT" to be invalid for calculating expiration."
  • 5 "If the Content-Length, ETag and Last-Modified values of a HEAD response (when present) are the same as that in a selected GET response (as per Section 4.3), the cache SHOULD update the remaining header fields in the stored response using the following rules..." (add "and the cache updates the stored response")

Change History (14)

comment:1 Changed 6 years ago by mnot@…

  • Summary changed from Srengthening SHOULDs to Strengthening SHOULDs

comment:2 Changed 6 years ago by fielding@…

From [2391]:

change to MUST the requirement on not sending Content-Length and Transfer-Encoding on 2xx responses to CONNECT; addresses #475

comment:3 Changed 6 years ago by fielding@…

P1 --

3.3.2 "A server SHOULD NOT send a Content-Length header field in any 2xx (Successful) response to a CONNECT request (Section 4.3.6 of [Part2])."

P2 --

4.3.6 "A server SHOULD NOT send any Transfer-Encoding or Content-Length header fields in a successful response." (CONNECT)

Both changed to MUST NOT in [2391]

4.3.6 "Proxies that support CONNECT SHOULD restrict its use to a limited set of known ports or a configurable whitelist of safe request targets."

That is an appropriate use of SHOULD.

comment:4 Changed 6 years ago by fielding@…

From [2392]:

clarify that recipients MUST parse for empty list elements; addresses #475

comment:5 Changed 6 years ago by fielding@…

P1 --

B "For compatibility with legacy list rules, recipients SHOULD accept empty list elements." (note that this requirement is in an appendix; it might be good to move it up)

Julian already moved it up to section 7. I changed it to a MUST in [2392], though with a qualification to say that we don't require parsing of infinite empty lists. I also clarified that the first expansion must be used by senders and the second by recipients, and that the collected ABNF shows the expansion for recipients?

Julian, why do we want to expand for recipients instead of senders? Is that for consistency with HTTP-date?

comment:6 Changed 6 years ago by fielding@…

  • Description modified (diff)
  • Milestone changed from unassigned to 24

almost there ...

comment:7 Changed 6 years ago by fielding@…

From [2395]:

strengthen response requirements on PUT when allowed for the target resource; addresses #475

comment:8 Changed 6 years ago by fielding@…

P2 --

4.3.4 "An origin server SHOULD reject any PUT request that contains a Content-Range header field"

Changed to MUST send 400 in this case, on target resources where PUT is allowed. [2395]

comment:9 Changed 6 years ago by fielding@…

From [2396]:

strengthen requirements on Referrer, rfc850-date, and Location fragment inheritance; addresses #475

comment:10 Changed 6 years ago by fielding@…

5.5.2 "A user agent SHOULD NOT send a Referer header field in an unsecured HTTP request if the referring page was received with a secure protocol."

Changed to MUST NOT send.

7.1.1.1 "Recipients of a timestamp value in rfc850-date format, which uses a two-digit year, SHOULD interpret a timestamp that appears to be more than 50 years in the future as representing the most recent year in the past that had the same last two digits."

Changed to MUST

7.1.2 "When Location is provided in a 3xx (Redirection) response and the URI reference that the user agent used to generate the request target contains a fragment identifier, the user agent SHOULD process the redirection as if the Location field value inherits the original fragment. In other words, if the Location does not have a fragment component, the user agent SHOULD interpret the Location reference as if it had the original reference's fragment." (note repeated requirement; second instance change to "can")

Changed to MUST and rephrased. [2396]

comment:11 Changed 6 years ago by fielding@…

From [2397]:

clarify requirements on non-GMT dates and updating stored GET responses with a HEAD response; addresses #475

comment:12 Changed 6 years ago by fielding@…

  • Description modified (diff)
  • Resolution set to incorporated
  • Status changed from new to closed

P6 --

4.1.3 "Cache recipients SHOULD consider a date with a zone abbreviation other than "GMT" to be invalid for calculating expiration."

No need to make that a MUST, though it should also allow UTC.

5 "If the Content-Length, ETag and Last-Modified values of a HEAD response (when present) are the same as that in a selected GET response (as per Section 4.3), the cache SHOULD update the remaining header fields in the stored response using the following rules..." (add "and the cache updates the stored response")

Choosing to do the update or invalidate is a SHOULD. If an update is done, the rules are a MUST. Rephrased and simplified, accordingly. [2397]

Finished.

comment:13 Changed 6 years ago by mnot@…

  • Resolution incorporated deleted
  • Status changed from closed to reopened

comment:14 Changed 6 years ago by mnot@…

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