SHOULD / RECOMMENDED
strong recommendation
there may be valid reasons to ignore this in particular circumstances, but the full implications must be understood and weighed
SHOULD and RECOMMENDED mark a strong recommendation, not a requirement. The spec is telling you: do this unless you have a specific, well-understood reason not to. SHOULD NOT / NOT RECOMMENDED is the inverse.
The practical trap: implementers treat SHOULD as MUST (over-strict) or as MAY (ignore it). Neither is right — SHOULD means deviate deliberately, not accidentally.
In the corpus (60 of 152)
HTTP Semantics
- RFC 9110 §2.2 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT"…
- RFC 9110 §2.3 A recipient SHOULD parse a received protocol element defensively, with only marginal expec…
- RFC 9110 §4.1 It is RECOMMENDED that all senders and recipients support, at a minimum, URIs with lengths…
- RFC 9110 §4.2.3 Two HTTP URIs that are equivalent after normalization (using any method) can be assumed to…
- RFC 9110 §4.2.4 Before making use of an "http" or "https" URI reference received from an untrusted source,…
- RFC 9110 §4.3.4 If the certificate is not valid for the target URI's origin, a user agent MUST either obta…
- RFC 9110 §5.1 A proxy MUST forward unrecognized header fields unless the field name is listed in the Con…
- RFC 9110 §5.5 Field values are usually constrained to the range of US-ASCII characters USASCII. Fields n…
- RFC 9110 §5.6.3 The OWS rule is used where zero or more linear whitespace octets might appear. For protoco…
- RFC 9110 §5.6.3 The RWS rule is used when at least one linear whitespace octet is required to separate fie…
- RFC 9110 §5.6.4 A sender SHOULD NOT generate a quoted-pair in a quoted-string except where necessary to qu…
- RFC 9110 §6.2 A client SHOULD send a request version equal to the highest version to which the client is…
- RFC 9110 §6.2 A server SHOULD send a response version equal to the highest version to which the server i…
- RFC 9110 §6.2 A recipient that receives a message with a major version number that it implements and a m…
- RFC 9110 §6.5.1 Because of the potential for trailer fields to be discarded in transit, a server SHOULD NO…
- RFC 9110 §6.6.1 A sender that generates a Date header field SHOULD generate its field value as the best av…
- RFC 9110 §6.6.2 A sender that intends to generate one or more trailer fields in a message SHOULD generate …
- RFC 9110 §7.2 The target URI's authority information is critical for handling a request. A user agent MU…
- RFC 9110 §7.5 A client that receives a response while it is still sending the associated request SHOULD …
- RFC 9110 §7.6.1 Furthermore, intermediaries SHOULD remove or replace fields that are known to require remo…
- RFC 9110 §7.6.3 An intermediary used as a portal through a network firewall SHOULD NOT forward the names a…
- RFC 9110 §7.6.3 A sender SHOULD NOT combine multiple list members unless they are all under the same organ…
- RFC 9110 §7.7 A proxy SHOULD NOT modify header fields that provide information about the endpoints of th…
- RFC 9110 §7.8 Although protocol names are registered with a preferred case, recipients SHOULD use case-i…
- RFC 9110 §8.3 A sender that generates a message containing content SHOULD generate a Content-Type header…
- RFC 9110 §8.4 If one or more encodings have been applied to a representation, the sender that applied th…
- RFC 9110 §8.4.1.1 The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding Welch that is commonly …
- RFC 9110 §8.4.1.3 The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy Check (CRC) that is co…
- RFC 9110 §8.6 A user agent SHOULD send Content-Length in a request when the method defines a meaning for…
- RFC 9110 §8.6 Aside from the cases defined above, in the absence of Transfer-Encoding, an origin server …
- RFC 9110 §8.8.1 An origin server SHOULD change a weak entity tag whenever it considers prior representatio…
- RFC 9110 §8.8.2.1 An origin server SHOULD send Last-Modified for any selected representation for which a las…
- RFC 9110 §8.8.2.1 An origin server SHOULD obtain the Last-Modified value of the representation as close as p…
- RFC 9110 §8.8.3.1 An origin server SHOULD send an ETag for any selected representation for which detection o…
- RFC 9110 §9.1 The set of methods allowed by a target resource can be listed in an Allow header field (Se…
- RFC 9110 §9.2.1 A user agent SHOULD distinguish between safe and unsafe methods when presenting potential …
- RFC 9110 §9.2.2 A client SHOULD NOT automatically retry a request with a non-idempotent method unless it h…
- RFC 9110 §9.2.2 A proxy MUST NOT automatically retry non-idempotent requests. A client SHOULD NOT automati…
- RFC 9110 §9.3.1 Although request message framing is independent of the method used, content received in a …
- RFC 9110 §9.3.2 The server SHOULD send the same header fields in response to a HEAD request as it would ha…
- RFC 9110 §9.3.2 Although request message framing is independent of the method used, content received in a …
- RFC 9110 §9.3.3 If one or more resources has been created on the origin server as a result of successfully…
- RFC 9110 §9.3.4 An origin server SHOULD verify that the PUT representation is consistent with its configur…
- RFC 9110 §9.3.4 This extends to how header and trailer fields are stored; while common header fields like …
- RFC 9110 §9.3.4 Proper interpretation of a PUT request presumes that the user agent knows which target res…
- RFC 9110 §9.3.5 If a DELETE method is successfully applied, the origin server SHOULD send
- RFC 9110 §9.3.5 Although request message framing is independent of the method used, content received in a …
- RFC 9110 §9.3.6 There are significant risks in establishing a tunnel to arbitrary servers, particularly wh…
- RFC 9110 §9.3.7 A server generating a successful response to OPTIONS SHOULD send any header that might ind…
- RFC 9110 §9.3.8 The TRACE method requests a remote, application-level loop-back of the request message. Th…
- RFC 9110 §9.3.8 A client MUST NOT generate fields in a TRACE request containing sensitive data that might …
- RFC 9110 §10.1.1 A client that sends a 100-continue expectation is not required to wait for any specific le…
- RFC 9110 §10.1.1 A client that receives a 417 (Expectation Failed) status code in response to a request con…
- RFC 9110 §10.1.1 A server that responds with a final status code before reading the entire request content …
- RFC 9110 §10.1.2 The From header field is rarely sent by non-robotic user agents. A user agent SHOULD NOT s…
- RFC 9110 §10.1.2 A robotic user agent SHOULD send a valid From header field so that the person responsible …
- RFC 9110 §10.1.2 A server SHOULD NOT use the From header field for access control or authentication, since …
- RFC 9110 §10.1.3 The Referer header field has the potential to reveal information about the request context…
- RFC 9110 §10.1.3 Some intermediaries have been known to indiscriminately remove Referer header fields from …
- RFC 9110 §10.1.5 The "User-Agent" header field contains information about the user agent originating the re…