MUST / REQUIRED / SHALL
absolute requirement
an absolute requirement of the specification — no conforming implementation may do otherwise
The requirement keywords, defined once in RFC 2119 (1997) and tightened by RFC 8174 (2017), are the backbone of every IETF spec. They only carry their special meaning in ALL CAPITALS — a lowercase "must" is just prose.
MUST, REQUIRED, and SHALL are equivalent: an absolute requirement. MUST NOT / SHALL NOT: an absolute prohibition. Violating a MUST means you are not implementing HTTP — full stop.
How it is read
RFC 2119 (1997)
spec
"MUST — This word, or the terms 'REQUIRED' or 'SHALL', mean that the definition is an absolute requirement of the specification." The document simply used capitalized keywords; whether lowercase counted was left ambiguous.
RFC 8174 (2017)
spec
Added the crucial clause: the keywords have their special meaning "only when they appear in all capitals, as shown here." A lowercase "must" is not a conformance requirement. RFC 9110 §2.2 adopts this: "The key words … are to be interpreted as described in BCP 14 … when, and only when, they appear in all capitals."
In the corpus (60 of 292)
HTTP Semantics
- RFC 9110 §2.2 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT"… HTTP's requirements-notation clause
- RFC 9110 §2.2 A sender MUST NOT generate protocol elements that do not match the grammar defined by the …
- RFC 9110 §2.3 At a minimum, a recipient MUST be able to parse and process protocol element lengths that …
- RFC 9110 §2.4 A recipient MUST interpret a received protocol element according to the semantics defined …
- RFC 9110 §3.3 As a result, a server MUST NOT assume that two requests on the same connection are from th…
- RFC 9110 §4.2.1 A sender MUST NOT generate an "http" URI with an empty host identifier. A recipient that p…
- RFC 9110 §4.2.2 A sender MUST NOT generate an "https" URI with an empty host identifier. A recipient that …
- RFC 9110 §4.2.2 A client MUST ensure that its HTTP requests for an "https" resource are secured, prior to …
- RFC 9110 §4.2.4 A sender MUST NOT generate the userinfo subcomponent (and its "@" delimiter) when an "http…
- RFC 9110 §4.3.4 To establish a secured connection to dereference a URI, a client MUST verify that the serv…
- RFC 9110 §4.3.4 In general, a client MUST verify the service identity using the verification process defin…
- RFC 9110 §4.3.4 A reference identity of type CN-ID MUST NOT be used by clients. As noted in RFC6125, a ref…
- 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.3 The order in which field lines with the same name are received is therefore significant to…
- RFC 9110 §5.3 This means that, aside from the well-known exception noted below, a sender MUST NOT genera…
- RFC 9110 §5.3 A server MUST NOT apply a request to the target resource until it receives the entire requ…
- RFC 9110 §5.4 A server that receives a request header field line, field value, or set of fields larger t…
- RFC 9110 §5.5 A field value does not include leading or trailing whitespace. When a specific version of …
- RFC 9110 §5.5 Field values containing CR, LF, or NUL characters are invalid and dangerous, due to the va…
- RFC 9110 §5.6.1.1 In any production that uses the list construct, a sender MUST NOT generate empty list elem…
- RFC 9110 §5.6.1.2 Empty elements do not contribute to the count of elements present. A recipient MUST parse …
- RFC 9110 §5.6.3 The BWS rule is used where the grammar allows optional whitespace only for historical reas…
- RFC 9110 §5.6.4 The backslash octet ("\") can be used as a single-octet quoting mechanism within quoted-st…
- RFC 9110 §5.6.7 A recipient that parses a timestamp value in an HTTP field MUST accept all three HTTP-date…
- RFC 9110 §5.6.7 A sender MUST NOT generate additional whitespace in an HTTP-date beyond that specifically …
- RFC 9110 §5.6.7 Recipients of a timestamp value in rfc850-date format, which uses a two-digit year, MUST i…
- RFC 9110 §6 Messages are intended to be "self-descriptive": everything a recipient needs to know about…
- 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.5.1 Many fields cannot be processed outside the header section because their evaluation is nec…
- RFC 9110 §6.5.1 Trailer fields can be difficult to process by intermediaries that forward messages from on…
- RFC 9110 §6.5.2 Like header fields, trailer fields with the same name are processed in the order received;…
- RFC 9110 §6.6.1 An origin server with a clock (as defined in Section 5.6.7) MUST generate a Date header fi…
- RFC 9110 §6.6.1 An origin server without a clock MUST NOT generate a Date header field.
- RFC 9110 §6.6.1 A recipient with a clock that receives a response message without a Date header field MUST…
- RFC 9110 §7.1 See the respective method definitions for details. These forms MUST NOT be used with other…
- RFC 9110 §7.2 The target URI's authority information is critical for handling a request. A user agent MU…
- RFC 9110 §7.4 Unless the connection is from a trusted gateway, an origin server MUST reject a request if…
- RFC 9110 §7.6 An intermediary not acting as a tunnel MUST implement the Connection header field, as spec…
- RFC 9110 §7.6 An intermediary MUST NOT forward a message to itself unless it is protected from an infini…
- RFC 9110 §7.6.1 When a field aside from Connection is used to supply control information for or about the …
- RFC 9110 §7.6.1 Intermediaries MUST parse a received Connection header field before a message is forwarded…
- RFC 9110 §7.6.1 A sender MUST NOT send a connection option corresponding to a field that is intended for a…
- RFC 9110 §7.6.2 Each intermediary that receives a TRACE or OPTIONS request containing a Max-Forwards heade…
- RFC 9110 §7.6.3 A proxy MUST send an appropriate Via header field, as described below, in each message tha…
- 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 If a proxy receives a target URI with a host name that is not a fully qualified domain nam…
- RFC 9110 §7.7 A proxy MUST NOT modify the "absolute-path" and "query" parts of the received target URI w…
- RFC 9110 §7.7 A proxy MUST NOT transform the content (Section 6.4) of a response message that contains a…
- RFC 9110 §7.8 A server that sends a 101 (Switching Protocols) response MUST send an Upgrade header field…
- RFC 9110 §7.8 A server that sends a 426 (Upgrade Required) response MUST send an Upgrade header field to…
- RFC 9110 §7.8 For example, if the Upgrade header field is received in a GET request and the server decid…
- RFC 9110 §7.8 A sender of Upgrade MUST also send an "Upgrade" connection option in the Connection header…
- RFC 9110 §7.8 A client cannot begin using an upgraded protocol on the connection until it has completely…
- RFC 9110 §8.3.3 MIME provides for a number of "multipart" types -- encapsulations of one or more represent…
- RFC 9110 §8.4 If one or more encodings have been applied to a representation, the sender that applied th…
- RFC 9110 §8.6 A server MAY send a Content-Length header field in a response to a HEAD request (Section 9…
- RFC 9110 §8.6 A server MAY send a Content-Length header field in a 304 (Not Modified) response to a cond…
- RFC 9110 §8.6 A server MUST NOT send a Content-Length header field in any response with a status code of…