📜 MUST, SHOULD, MAY (RFC 2119)

RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3
Section 9.1. Mandatory-to-Implement Cipher Suites

   A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256
   [GCM] cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384
   [GCM] and TLS_CHACHA20_POLY1305_SHA256 [RFC8439] cipher suites (see
   Appendix B.4).

   A TLS-compliant application MUST support digital signatures with
   rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for
   CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A
   TLS-compliant application MUST support key exchange with secp256r1
   (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748].

RFC 6265 — HTTP State Management Mechanism
Section 4.1.2.5. The Secure Attribute

   The Secure attribute limits the scope of the cookie to "secure"
   channels (where "secure" is defined by the user agent).  When a
   cookie has the Secure attribute, the user agent will include the
   cookie in an HTTP request only if the request is transmitted over a
   secure channel (typically HTTP over Transport Layer Security (TLS)).

   Although seemingly useful for protecting cookies from active network
   attackers, the Secure attribute protects only the cookie's
   confidentiality.  An active network attacker can overwrite Secure
   cookies from an insecure channel, disrupting their integrity.

   The user agent MUST NOT include more than one Set-Cookie header field
   in the same response with the same cookie-name.

RFC 7231 — HTTP/1.1: Semantics and Content
Section 6.6.4. 503 Service Unavailable

   The 503 (Service Unavailable) status code indicates that the server
   is currently unable to handle the request due to a temporary overload
   or scheduled maintenance, which will likely be alleviated after some
   delay.  The server MAY send a Retry-After header field to suggest an
   appropriate amount of time for the client to wait before retrying the
   request.

   Note: The existence of the 503 status code does not imply that a
   server has to use it when becoming overloaded.  Some servers might
   wish to simply refuse the connection.

RFC 2119 — Key words for use in RFCs to Indicate Requirement Levels

   5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
            truly optional.  One vendor may choose to include the item
            because a particular marketplace requires it or because the
            vendor feels that it enhances the product while another
            vendor may omit the same item.  An implementation which does
            not include a particular option MUST be prepared to
            interoperate with another implementation which does include
            the option, though perhaps with reduced functionality.  In
            the same vein an implementation which does include a
            particular option MUST be prepared to interoperate with
            another implementation which does not include the option
            (except, of course, for the feature the option provides).

RFC 7234 — HTTP/1.1: Caching
Section 5.2.2.8. no-store

   The "no-store" response directive indicates that a cache MUST NOT
   store any part of either the immediate request or response.  This
   directive applies to both private and shared caches.  "MUST NOT
   store" in this context means that the cache MUST NOT intentionally
   store the information in non-volatile storage, and MUST make a
   best-effort attempt to remove the information from volatile storage
   as promptly as possible after forwarding it.

   This directive is NOT a reliable or sufficient mechanism for ensuring
   privacy.  In particular, malicious or compromised caches might not
   recognize or obey this directive, and communications networks might
   be vulnerable to eavesdropping.