search

httpwg / httpbis-issues

1 stars 1 forks source link

Strengthening SHOULDs #475

Closed mnot closed 4 years ago

mnot commented 11 years ago

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

P2

P6

Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/475

mnot commented 11 years ago

@mnot changed summary from Srengthening SHOULDs to Strengthening SHOULDs

mnot commented 11 years ago

fielding@gbiv.com commented:

From 2391:

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

mnot commented 11 years ago

fielding@gbiv.com commented:

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.

mnot commented 11 years ago

fielding@gbiv.com commented:

From 2392:

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

mnot commented 11 years ago

fielding@gbiv.com commented:

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?

mnot commented 11 years ago

almost there ...

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

to:

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

mnot commented 11 years ago

fielding@gbiv.com commented:

From 2395:

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

mnot commented 11 years ago

fielding@gbiv.com commented:

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

mnot commented 11 years ago

fielding@gbiv.com commented:

From 2396:

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

mnot commented 11 years ago

fielding@gbiv.com commented:

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

mnot commented 11 years ago

fielding@gbiv.com commented:

From 2397:

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

mnot commented 11 years ago

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.

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

to:

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

mnot commented 11 years ago
mnot commented 11 years ago