MAY / OPTIONAL
truly optional
genuinely optional — one implementation may do it, another may not, and both conform; neither side may assume the other's choice
MAY and OPTIONAL mean an item is truly optional. RFC 2119 adds the part people forget: an implementation that does not include the option MUST be prepared to interoperate with one that does (and vice versa) — you can't require a peer to have made the same optional choice you did.
In the corpus (60 of 146)
HTTP Semantics
- RFC 9110 §2.2 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT"…
- RFC 9110 §2.2 When an implementation fails semantic conformance, recipients of that implementation's mes…
- RFC 9110 §2.4 Unless noted otherwise, a recipient MAY attempt to recover a usable protocol element from …
- RFC 9110 §3.8 A "cache" is a local store of previous response messages and the subsystem that controls i…
- RFC 9110 §4.2.3 Two HTTP URIs that are equivalent after normalization (using any method) can be assumed to…
- RFC 9110 §4.3.2 When an "http" URI is used within a context that calls for access to the indicated resourc…
- RFC 9110 §4.3.3 When an "https" URI is used within a context that calls for access to the indicated resour…
- 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.3 A recipient MAY combine multiple field lines within a field section that have the same fie…
- RFC 9110 §5.4 A client MAY discard or truncate received field lines that are larger than the client wish…
- RFC 9110 §5.5 Field values containing CR, LF, or NUL characters are invalid and dangerous, due to the va…
- RFC 9110 §5.6.3 OWS and RWS have the same semantics as a single SP. Any content known to be defined as OWS…
- RFC 9110 §5.6.3 BWS has no semantics. Any content known to be defined as BWS MAY be removed before interpr…
- RFC 9110 §6.2 A client MAY send a lower request version if it is known that the server incorrectly imple…
- RFC 9110 §6.5.2 At the end of a message, a recipient MAY treat the set of received trailer fields as a dat…
- 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 A recipient with a clock that receives a response with an invalid Date header field value …
- RFC 9110 §6.6.1 A user agent MAY send a Date header field in a request, though generally will not do so un…
- RFC 9110 §7.6.2 A recipient MAY ignore a Max-Forwards header field received with any other request methods…
- 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 The received-by portion is normally the host and optional port number of a recipient serve…
- RFC 9110 §7.6.3 A sender MAY generate comments to identify the software of each recipient, analogous to th…
- RFC 9110 §7.6.3 An intermediary MAY combine an ordered subsequence of Via header field list members into a…
- 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 MAY transform the content of a message that does not contain a no-transform cache …
- RFC 9110 §7.8 A client MAY send a list of protocol names in the Upgrade header field of a request to inv…
- 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 MAY send an Upgrade header field in any other response to advertise that it imple…
- RFC 9110 §8.3 A sender that generates a message containing content SHOULD generate a Content-Type header…
- RFC 9110 §8.3.1 The type/subtype MAY be followed by semicolon-delimited parameters (Section 5.6.6) in the …
- RFC 9110 §8.4 An origin server MAY respond with a status code of 415 (Unsupported Media Type) if a repre…
- RFC 9110 §8.5 Multiple languages MAY be listed for content that is intended for multiple audiences. For …
- RFC 9110 §8.5 Content-Language MAY be applied to any media type -- it is not limited to textual document…
- 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 Likewise, a sender MUST NOT forward a message with a Content-Length header field value tha…
- RFC 9110 §8.7 If Content-Location is included in a 2xx (Successful) response message and its value refer…
- RFC 9110 §8.7 An origin server that receives a Content-Location field in a request message MUST treat th…
- RFC 9110 §8.8.3 A sender MAY send the ETag field in a trailer section (see Section 6.5). However, since tr…
- RFC 9110 §9.1 All general-purpose servers MUST support the methods GET and HEAD. All other methods are O…
- RFC 9110 §9.3.1 The response to a GET request is cacheable; a cache MAY use it to satisfy subsequent GET 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 The response to a HEAD request is cacheable; a cache MAY use it to satisfy subsequent HEAD…
- RFC 9110 §9.3.3 If the result of processing a POST would be equivalent to a representation of an existing …
- RFC 9110 §9.3.4 Proper interpretation of a PUT request presumes that the user agent knows which target res…
- RFC 9110 §9.3.6 CONNECT is intended for use in requests to a proxy. The recipient can establish a tunnel e…
- RFC 9110 §9.3.7 A client MAY send a Max-Forwards header field in an OPTIONS request to target a specific r…
- RFC 9110 §10.1.1 A server that receives an Expect field value containing a member other than 100-continue M…
- 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 server MAY omit sending a 100 (Continue) response if it has already received some or all…
- RFC 9110 §10.1.1 If the proxy believes (from configuration or past interaction) that the next inbound serve…
- RFC 9110 §10.1.3 The Referer header field value need not convey the full URI of the referring resource; a u…
- RFC 9110 §10.2.1 The actual set of allowed methods is defined by the origin server at the time of each requ…
- RFC 9110 §10.2.4 The "Server" header field contains information about the software used by the origin serve…
- RFC 9110 §11.5 The protection space determines the domain over which credentials can be automatically app…
- RFC 9110 §11.6.1 A server generating a 401 (Unauthorized) response MUST send a WWW-Authenticate header fiel…
- RFC 9110 §11.7.2 Unlike Authorization, the Proxy-Authorization header field applies only to the next inboun…
- RFC 9110 §12.1 Proactive negotiation is advantageous when the algorithm for selecting from among the avai…
- RFC 9110 §12.5.2 Charset names are defined in Section 8.3.2. A user agent MAY associate a quality value wit…
- RFC 9110 §12.5.3 Each codings value MAY be given an associated quality value (weight) representing the pref…