RFC Requirement Dashboard

This dashboard classifies every Http11Probe test by its RFC 2119 requirement level (MUST, SHOULD, MAY, “ought to”), with the exact RFC quote that proves it. Tests are grouped by requirement level, then by suite.

Summary

Requirement LevelCountMeaning (RFC 2119)
MUST113Absolute requirement — no compliant implementation may deviate
SHOULD29Recommended — valid exceptions exist but must be understood
MAY10Truly optional — either behavior is fully compliant
“ought to”1Weaker than SHOULD — recommended but not normative
Unscored51Informational — no pass/fail judgement
N/A11Best-practice / no single RFC verb applies

Total: 215 tests

MUST-Level Requirements (113 tests)

These tests enforce absolute RFC requirements. A compliant server has no discretion — it MUST behave as specified.

MUST — Reject with 400 (No Alternatives)

These are the strictest tests: the RFC mandates exactly 400 (Bad Request). Connection close alone does not satisfy the requirement.

#Test IDSuiteRFCRFC Quote
1RFC9110-5.6.2-SP-BEFORE-COLONComplianceRFC 9112 §5.1“A server MUST reject, with a response status code of 400 (Bad Request), any received request message that contains whitespace between a header field name and colon.”
2RFC9112-5.1-OBS-FOLDComplianceRFC 9112 §5.2“A server that receives an obs-fold in a request message that is not within a ‘message/http’ container MUST either reject the message by sending a 400 (Bad Request)… or replace each received obs-fold with one or more SP octets.”
3RFC9112-7.1-MISSING-HOSTComplianceRFC 9112 §3.2“A server MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and to any request message that contains more than one Host header field line or a Host header field with an invalid field value.”
4RFC9110-5.4-DUPLICATE-HOSTComplianceRFC 9112 §3.2“A server MUST respond with a 400 (Bad Request) status code to any… request message that contains more than one Host header field line or a Host header field with an invalid field value.”
5COMP-DUPLICATE-HOST-SAMEComplianceRFC 9112 §3.2“A server MUST respond with a 400 (Bad Request) status code to any… request message that contains more than one Host header field line…” (applies even when both values are identical)
6RFC9112-3-CR-ONLY-LINE-ENDINGComplianceRFC 9112 §2.2“A recipient of such a bare CR MUST consider that element to be invalid or replace each bare CR with SP before processing the element or forwarding the message.”

MUST — Reject (400 or Connection Close Acceptable)

The RFC requires rejection, but the mechanism (400 status or connection close) has some flexibility.

#Test IDSuiteRFCRFC Quote
7RFC9112-5-EMPTY-HEADER-NAMEComplianceRFC 9112 §5Grammar: field-name = token, token = 1*tchar. An empty field name violates 1*tchar (requires at least one character).
8RFC9112-5-INVALID-HEADER-NAMEComplianceRFC 9112 §5Grammar: token = 1*tchar, tchar = "!" / "#" / .... Brackets are not in the tchar set — implicit MUST reject.
9RFC9112-5-HEADER-NO-COLONComplianceRFC 9112 §5Grammar: field-line = field-name ":" OWS field-value OWS. The colon is mandatory — implicit MUST reject.
10COMP-WHITESPACE-BEFORE-HEADERSComplianceRFC 9112 §2.2“A recipient that receives whitespace between the start-line and the first header field MUST either reject the message as invalid or consume each whitespace-preceded line without further processing.”
11RFC9112-3-MISSING-TARGETComplianceRFC 9112 §3Grammar: request-line = method SP request-target SP HTTP-version. Missing target violates mandatory grammar — implicit MUST.
12COMP-ASTERISK-WITH-GETComplianceRFC 9112 §3.2.4“If a proxy receives an OPTIONS request with an absolute-form of request-target in which the URI has an empty path and no query component, then the last proxy on the request chain MUST send a request-target of ‘*’ when it forwards the request to the indicated origin server.” Only OPTIONS may use asterisk-form.
13COMP-HOST-WITH-USERINFOComplianceRFC 9112 §3.2“A server MUST respond with a 400 (Bad Request)… to any request message that contains… a Host header field with an invalid field value.” (userinfo component is not valid in Host)
14COMP-HOST-WITH-PATHComplianceRFC 9112 §3.2“A server MUST respond with a 400 (Bad Request)… to any request message that contains… a Host header field with an invalid field value.” (path component is not valid in Host)
15COMP-HOST-EMPTY-VALUEComplianceRFC 9112 §3.2“A server MUST respond with a 400 (Bad Request)… to any request message that contains… a Host header field with an invalid field value.”
16COMP-VERSION-MISSING-MINORComplianceRFC 9112 §2.3Grammar: HTTP-version = HTTP-name "/" DIGIT "." DIGIT. “HTTP/1” has no minor version digit — violates the grammar. MUST reject.
17COMP-VERSION-LEADING-ZEROSComplianceRFC 9112 §2.3Grammar: HTTP-version = HTTP-name "/" DIGIT "." DIGIT. Each version component is exactly one DIGIT — “01” is two digits. MUST reject.
18COMP-VERSION-WHITESPACEComplianceRFC 9112 §2.3Grammar: HTTP-version = HTTP-name "/" DIGIT "." DIGIT. No whitespace is permitted within the version token. MUST reject.
19COMP-VERSION-CASEComplianceRFC 9112 §2.3“HTTP-version is case-sensitive.” HTTP-name = %x48.54.54.50 — only uppercase octets match. MUST reject lowercase http/1.1.
20COMP-SPACE-IN-TARGETComplianceRFC 9112 §3.2Unencoded space in request-target makes the request-line ambiguous (four tokens instead of three). Grammar: request-line = method SP request-target SP HTTP-version. MUST reject.
19RFC9112-6.1-CL-NON-NUMERICComplianceRFC 9112 §6.3“If a message is received without Transfer-Encoding and with an invalid Content-Length header field, then the message framing is invalid and the recipient MUST treat it as an unrecoverable error… the server MUST respond with a 400 (Bad Request) status code and then close the connection.”
20RFC9112-6.1-CL-PLUS-SIGNComplianceRFC 9112 §6.3Same as above — Content-Length = 1*DIGIT. A plus sign is not a DIGIT. MUST reject as invalid Content-Length.
21SMUG-DUPLICATE-CLSmugglingRFC 9110 §8.6“If a message is received without Transfer-Encoding and with an invalid Content-Length header field, then the message framing is invalid and the recipient MUST treat it as an unrecoverable error.” Duplicate CL with different values = invalid.
22SMUG-CL-COMMA-DIFFERENTSmugglingRFC 9110 §8.6Same as above — comma-separated Content-Length values that differ are invalid. MUST treat as unrecoverable error.
23SMUG-CL-NEGATIVESmugglingRFC 9110 §8.6Content-Length = 1*DIGIT. A minus sign is not a DIGIT. Invalid Content-Length — MUST reject.
24SMUG-CL-NEGATIVE-ZEROSmugglingRFC 9110 §8.6Content-Length = 1*DIGIT. “-0” starts with a minus sign. Invalid Content-Length — MUST reject.
25SMUG-CL-UNDERSCORESmugglingRFC 9110 §8.6Content-Length = 1*DIGIT. Underscore is not a DIGIT. Invalid Content-Length — MUST reject.
26SMUG-CL-OCTALSmugglingRFC 9110 §8.6Content-Length = 1*DIGIT. “0o5” contains non-DIGIT characters. MUST reject.
27SMUG-CL-HEX-PREFIXSmugglingRFC 9110 §8.6Content-Length = 1*DIGIT. “0x5” contains ‘x’. MUST reject.
28SMUG-CL-INTERNAL-SPACESmugglingRFC 9110 §8.6Content-Length = 1*DIGIT. Space is not a DIGIT and not OWS within the value. MUST reject.
29SMUG-TE-SP-BEFORE-COLONSmugglingRFC 9112 §5.1“A server MUST reject, with a response status code of 400 (Bad Request), any received request message that contains whitespace between a header field name and colon.” (Same rule as SP-BEFORE-COLON, applied to Transfer-Encoding.)
30SMUG-TE-NOT-FINAL-CHUNKEDSmugglingRFC 9112 §6.3“If a Transfer-Encoding header field is present in a request and the chunked transfer coding is not the final encoding, the message body length cannot be determined reliably; the server MUST respond with the 400 (Bad Request) status code and then close the connection.”
31SMUG-TE-HTTP10SmugglingRFC 9112 §6.1“A server or client that receives an HTTP/1.0 message containing a Transfer-Encoding header field MUST treat the message as if the framing is faulty, even if a Content-Length is present, and close the connection after processing the message.”
32SMUG-TE-EMPTY-VALUESmugglingRFC 9112 §6.1Transfer-Encoding = #transfer-coding, transfer-coding = token = 1*tchar. An empty value does not match 1*tchar. MUST reject.
33SMUG-TE-DUPLICATE-HEADERSSmugglingRFC 9112 §6.1Two Transfer-Encoding headers with conflicting Content-Length creates ambiguous framing. The combined TE + CL violates “A sender MUST NOT send a Content-Length header field in any message that contains a Transfer-Encoding header field.” MUST reject.
34SMUG-TE-IDENTITYSmugglingRFC 9112 §7“The ‘identity’ transfer coding was used in HTTP/1.1 and has been removed from the registry.” An unrecognized coding with CL present. MUST reject per §6.1.
35SMUG-TE-VTABSmugglingRFC 9112 §6.1transfer-coding = token = 1*tchar. Vertical tab (0x0B) is not a tchar. The TE value is syntactically invalid — MUST reject.
36SMUG-TE-FORMFEEDSmugglingRFC 9112 §6.1transfer-coding = token = 1*tchar. Form feed (0x0C) is not a tchar. The TE value is syntactically invalid — MUST reject.
37SMUG-TE-NULLSmugglingRFC 9110 §5.5“Field values containing CR, LF, or NUL characters are invalid and dangerous… a recipient of CR, LF, or NUL within a field value MUST either reject the message or replace each of those characters with SP before further processing.”
38SMUG-BARE-CR-HEADER-VALUESmugglingRFC 9112 §2.2“A recipient of such a bare CR MUST consider that element to be invalid or replace each bare CR with SP before processing the element or forwarding the message.”
39SMUG-MULTIPLE-HOST-COMMASmugglingRFC 9110 §7.2“A server MUST respond with a 400 (Bad Request)… to any request message that contains… a Host header field with an invalid field value.” Comma-separated values in Host are invalid.
40SMUG-TE-OBS-FOLDSmugglingRFC 9112 §5.2“A server that receives an obs-fold in a request message… MUST either reject the message by sending a 400 (Bad Request)… or replace each received obs-fold with one or more SP octets.”
41SMUG-CHUNK-BARE-SEMICOLONSmugglingRFC 9112 §7.1.1Grammar: chunk-ext = *( BWS ";" BWS chunk-ext-name [ "=" chunk-ext-val ] ), chunk-ext-name = token = 1*tchar. Bare semicolon with no name violates the grammar. MUST reject.
42SMUG-CHUNK-HEX-PREFIXSmugglingRFC 9112 §7.1Grammar: chunk-size = 1*HEXDIG. “0x” prefix is not valid HEXDIG. MUST reject.
43SMUG-CHUNK-UNDERSCORESmugglingRFC 9112 §7.1Grammar: chunk-size = 1*HEXDIG. Underscore is not a HEXDIG. MUST reject.
44SMUG-CHUNK-LEADING-SPSmugglingRFC 9112 §7.1Grammar: chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF. No leading whitespace is permitted before chunk-size. MUST reject.
45SMUG-CHUNK-MISSING-TRAILING-CRLFSmugglingRFC 9112 §7.1Grammar: chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF. The trailing CRLF after chunk-data is mandatory. MUST reject.
46SMUG-CHUNK-SPILLSmugglingRFC 9112 §7.1Chunk declares size 5 but sends 7 bytes. Server MUST read exactly chunk-size octets. Extra bytes corrupt framing. MUST reject.
47SMUG-CHUNK-NEGATIVESmugglingRFC 9112 §7.1Grammar: chunk-size = 1*HEXDIG. A minus sign is not a HEXDIG. MUST reject.
48SMUG-CHUNK-EXT-CTRLSmugglingRFC 9112 §7.1.1NUL byte (0x00) in chunk extension. NUL is not valid in any HTTP protocol element. RFC 9110 §5.5: “a recipient of CR, LF, or NUL within a field value MUST either reject the message or replace each of those characters with SP.”
49SMUG-CHUNK-EXT-CRSmugglingRFC 9112 §2.2“A recipient of such a bare CR MUST consider that element to be invalid or replace each bare CR with SP before processing the element or forwarding the message.” Bare CR in chunk extension is invalid.
50SMUG-CHUNK-BARE-CR-TERMSmugglingRFC 9112 §2.2“A recipient of such a bare CR MUST consider that element to be invalid or replace each bare CR with SP.” Bare CR as line terminator is invalid — MUST reject.
51SMUG-CLTE-PIPELINESmugglingRFC 9112 §6.1“Regardless, the server MUST close the connection after responding to such a request to avoid the potential attacks.” CL+TE combined — MUST close connection.
52SMUG-TECL-PIPELINESmugglingRFC 9112 §6.1Same as above — TE+CL combined in reverse smuggling direction. MUST close connection.
53SMUG-TE-XCHUNKEDSmugglingRFC 9112 §6.1Unknown TE with CL present: “Regardless, the server MUST close the connection after responding to such a request.” Combined with §6.1: “A server that receives a request message with a transfer coding it does not understand SHOULD respond with 501.”
54SMUG-CLTE-CONN-CLOSESmugglingRFC 9112 §6.1Sequence test: CL+TE combined, then follow-up GET on same socket. “The server MUST close the connection after responding to such a request.” If follow-up receives a response, MUST-close violated.
55SMUG-TECL-CONN-CLOSESmugglingRFC 9112 §6.1Same as CLTE-CONN-CLOSE with TE before CL header order. MUST close connection.
57SMUG-CLTE-DESYNCSmugglingRFC 9112 §6.1Classic CL.TE desync: CL=6 with TE=chunked body 0\r\n\r\nX. Poison byte after CL boundary confirms desync. MUST close connection.
58SMUG-CLTE-SMUGGLED-GETSmugglingRFC 9112 §6.1CL.TE desync payload where the trailing bytes form a full GET / request. If the server returns multiple HTTP responses on one send, the embedded request was executed. “Regardless, the server MUST close the connection after responding to such a request.”
59SMUG-TECL-DESYNCSmugglingRFC 9112 §6.1Reverse TE.CL desync: TE=chunked terminates at 0\r\n\r\n but CL=30. Extra bytes on wire confirm desync. MUST close connection.
60SMUG-CHUNK-SIZE-PLUSSmugglingRFC 9112 §7.1Grammar: chunk-size = 1*HEXDIG. Leading + is not HEXDIG; invalid chunk framing MUST be rejected.
61SMUG-CHUNK-SIZE-TRAILING-OWSSmugglingRFC 9112 §7.1Grammar: chunk-size = 1*HEXDIG. Trailing whitespace in chunk-size is invalid syntax and MUST be rejected.
62SMUG-CHUNK-EXT-INVALID-TOKENSmugglingRFC 9112 §7.1.1Grammar: chunk-ext-name = token. [ is not a valid token character, so the chunk extension is invalid and MUST be rejected.
63SMUG-OPTIONS-TE-OBS-FOLDSmugglingRFC 9112 §5.2“A server that receives an obs-fold in a request message … MUST either reject the message by sending a 400 (Bad Request) … or replace each received obs-fold with one or more SP octets.”
64SMUG-CHUNK-INVALID-SIZE-DESYNCSmugglingRFC 9112 §7.1Sequence test with invalid +0 chunk-size plus poison byte. Since chunk-size = 1*HEXDIG, this framing error MUST be rejected to prevent desync.
54COMP-CONNECTION-CLOSEComplianceRFC 9112 §9.6“A server that receives a ‘close’ connection option MUST initiate closure of the connection after it sends the final response to the request that contained the ‘close’ connection option.”
55COMP-OPTIONS-STARComplianceRFC 9112 §3.2.4The asterisk-form * is defined only for OPTIONS. A valid OPTIONS * request MUST be accepted.
56COMP-POST-CL-BODYComplianceRFC 9112 §6.2“If a valid Content-Length header field is present without Transfer-Encoding, its decimal value defines the expected message body length in octets.” Server MUST accept a well-formed POST with matching body.
57COMP-POST-CL-ZEROComplianceRFC 9112 §6.2Content-Length: 0 is a valid 1*DIGIT value. Server MUST accept zero-length body.
58COMP-POST-NO-CL-NO-TEComplianceRFC 9112 §6.3“If this is a request message and none of the above are true, then the message body length is zero (no message body is present).” Server MUST treat as zero-length.
59COMP-RANGE-POSTComplianceRFC 9110 §14.2“A server MUST ignore a Range header field received with a request method other than GET.”
60COMP-UPGRADE-HTTP10ComplianceRFC 9110 §7.8“A server MUST ignore an Upgrade header field that is received in an HTTP/1.0 request.”
59COMP-CHUNKED-BODYComplianceRFC 9112 §7.1“A recipient MUST be able to parse and decode the chunked transfer coding.”
60COMP-CHUNKED-MULTIComplianceRFC 9112 §7.1Same — multi-chunk is the standard chunked format. MUST accept.
61COMP-CHUNKED-EMPTYComplianceRFC 9112 §7.1A zero-length chunked body (just 0\r\n\r\n) is valid. MUST accept.
62COMP-CHUNKED-HEX-UPPERCASEComplianceRFC 9112 §7.1chunk-size = 1*HEXDIG. HEXDIG includes A-F. MUST accept uppercase hex.
63COMP-CHUNKED-TRAILER-VALIDComplianceRFC 9112 §7.1.2“A recipient MUST be able to parse and decode the chunked transfer coding.” Trailers are part of the chunked format. MUST accept.
64COMP-CHUNKED-EXTENSIONComplianceRFC 9112 §7.1.1“A recipient MUST ignore unrecognized chunk extensions.” Server MUST accept and ignore.
65COMP-POST-CL-UNDERSENDComplianceRFC 9112 §6.2“If the sender closes the connection or the recipient times out before the indicated number of octets are received, the recipient MUST consider the message to be incomplete and close the connection.”
66COMP-CHUNKED-NO-FINALComplianceRFC 9112 §7.1“The message body length is determined by reading and decoding the chunked data until the transfer coding indicates the data is complete.” Without a zero terminator, the transfer is incomplete. Server MUST not process as complete.
67COMP-UPGRADE-POSTComplianceRFC 6455 §4.1“The method of the request MUST be GET, and the HTTP version MUST be at least 1.1.” WebSocket upgrade via POST MUST not succeed.
68COMP-UPGRADE-MISSING-CONNComplianceRFC 9110 §7.8“A sender of Upgrade MUST also send an ‘Upgrade’ connection option in the Connection header field.” Without Connection: Upgrade, the server MUST NOT switch protocols.
69COMP-UPGRADE-UNKNOWNComplianceRFC 9110 §7.8“A server MUST NOT switch to a protocol that was not indicated by the client in the corresponding request’s Upgrade header field.” Unknown protocol — MUST NOT return 101.
70MAL-NUL-IN-URLMalformedRFC 9112 §2.2NUL byte is not valid in any protocol element. Grammar violation — MUST reject.
71MAL-CONTROL-CHARS-HEADERMalformedRFC 9110 §5.5“Field values containing CR, LF, or NUL characters are invalid and dangerous… a recipient MUST either reject the message or replace each of those characters with SP.” (CTL characters outside safe context.)
72MAL-NON-ASCII-HEADER-NAMEMalformedRFC 9112 §5field-name = token = 1*tchar. Non-ASCII bytes are not tchar. Grammar violation — MUST reject.
73MAL-NON-ASCII-URLMalformedRFC 9112 §3Non-ASCII bytes in the request-target violate the URI grammar. “A recipient SHOULD NOT attempt to autocorrect… since the invalid request-line might be deliberately crafted to bypass security filters.”
74MAL-CL-OVERFLOWMalformedRFC 9110 §8.6“A recipient MUST anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows or precision loss due to integer conversion.”
75MAL-NUL-IN-HEADER-VALUEMalformedRFC 9110 §5.5“Field values containing CR, LF, or NUL characters are invalid and dangerous… a recipient of CR, LF, or NUL within a field value MUST either reject the message or replace each of those characters with SP.”
76MAL-CHUNK-SIZE-OVERFLOWMalformedRFC 9112 §7.1“Recipients MUST anticipate potentially large hexadecimal numerals and prevent parsing errors due to integer conversion overflows or precision loss due to integer conversion.”
77MAL-CL-EMPTYMalformedRFC 9110 §8.6Content-Length = 1*DIGIT. Empty value does not match 1*DIGIT (requires at least one). MUST reject as invalid CL.
78MAL-URL-OVERLONG-UTF8MalformedRFC 3629 §3“Implementations of the decoding algorithm above MUST protect against decoding invalid sequences.” Overlong UTF-8 (0xC0 0xAF) is explicitly invalid per RFC 3629.
79NORM-SP-BEFORE-COLON-CLNormalizationRFC 9112 §5.1“A server MUST reject, with a response status code of 400 (Bad Request), any received request message that contains whitespace between a header field name and colon.”
80NORM-TAB-IN-NAMENormalizationRFC 9112 §5field-name = token = 1*tchar. Tab (0x09) is not a tchar. MUST reject — invalid token character.
81COMP-UPGRADE-INVALID-VERComplianceRFC 6455 §4.4“If the server doesn’t support the requested version, it MUST abort the WebSocket handshake.” (426 Upgrade Required preferred.)
82COMP-UNKNOWN-TE-501ComplianceRFC 9112 §6.1“A server that receives a request message with a transfer coding it does not understand SHOULD respond with 501.” Combined with unknown-TE-without-CL making body length indeterminate: MUST reject.
83SMUG-TE-TRAILING-SPACESmugglingRFC 9112 §6.1“chunked " (with trailing space) is not an exact match for the registered coding “chunked”. Combined with CL present: “the server MUST close the connection after responding.”
84MAL-POST-CL-HUGE-NO-BODYMalformedRFC 9112 §6.2“If the sender closes the connection or the recipient times out before the indicated number of octets are received, the recipient MUST consider the message to be incomplete and close the connection.”
85COMP-HEAD-NO-BODYComplianceRFC 9110 §9.3.2“The HEAD method is identical to GET except that the server MUST NOT send content in the response.”
86COMP-405-ALLOWComplianceRFC 9110 §15.5.6“The origin server MUST generate an Allow header field in a 405 response containing a list of the target resource’s currently supported methods.”
87COMP-DATE-HEADERComplianceRFC 9110 §6.6.1“An origin server with a clock MUST generate a Date header field in all 2xx (Successful), 3xx (Redirection), and 4xx (Client Error) responses.”
88COMP-NO-1XX-HTTP10ComplianceRFC 9110 §15.2“Since HTTP/1.0 did not define any 1xx status codes, a server MUST NOT send a 1xx response to an HTTP/1.0 client.”
89COMP-NO-CL-IN-204ComplianceRFC 9110 §8.6“A server MUST NOT send a Content-Length header field in any response with a status code of 1xx (Informational) or 204 (No Content).”
90SMUG-CLTE-SMUGGLED-GET-CL-PLUSSmugglingRFC 9112 §6.1Variant of SMUG-CLTE-SMUGGLED-GET with Content-Length: +N (malformed CL) and Transfer-Encoding: chunked, embedding a full GET / in the body. “Regardless, the server MUST close the connection after responding to such a request.”
91SMUG-CLTE-SMUGGLED-GET-CL-NON-NUMERICSmugglingRFC 9112 §6.1Variant of SMUG-CLTE-SMUGGLED-GET with Content-Length: N<alpha> (non-numeric suffix) and Transfer-Encoding: chunked, embedding a full GET / in the body. “Regardless, the server MUST close the connection after responding to such a request.”
92SMUG-CLTE-SMUGGLED-GET-TE-OBS-FOLDSmugglingRFC 9112 §5.2Variant of SMUG-CLTE-SMUGGLED-GET with obs-folded Transfer-Encoding:\r\n chunked plus Content-Length, embedding a full GET / in the body. “A server that receives an obs-fold in a request message… MUST either reject the message by sending a 400 (Bad Request)… or replace each received obs-fold with one or more SP octets prior to interpreting the field value…”
93SMUG-CLTE-SMUGGLED-HEADSmugglingRFC 9112 §6.1Embedded-request confirmation variant using a smuggled HEAD / request. “Regardless, the server MUST close the connection after responding to such a request.”
94SMUG-CLTE-SMUGGLED-GET-TE-TRAILING-SPACESmugglingRFC 9112 §6.1Variant of SMUG-CLTE-SMUGGLED-GET with Transfer-Encoding: chunked␠ (trailing space) plus Content-Length. “Regardless, the server MUST close the connection after responding to such a request.”
95SMUG-CLTE-SMUGGLED-GET-TE-LEADING-COMMASmugglingRFC 9112 §6.1Variant of SMUG-CLTE-SMUGGLED-GET with Transfer-Encoding: , chunked plus Content-Length. “Regardless, the server MUST close the connection after responding to such a request.”
96SMUG-CLTE-SMUGGLED-GET-TE-CASE-MISMATCHSmugglingRFC 9112 §6.1Variant of SMUG-CLTE-SMUGGLED-GET with Transfer-Encoding: Chunked (case mismatch) plus Content-Length. “Regardless, the server MUST close the connection after responding to such a request.”
97SMUG-TE-DUPLICATE-HEADERS-SMUGGLED-GETSmugglingRFC 9112 §6.1Sequence confirmation variant using duplicate Transfer-Encoding header fields (chunked + identity) plus Content-Length, embedding a full GET / in the body. “Regardless, the server MUST close the connection after responding to such a request.”
98SMUG-TECL-SMUGGLED-GETSmugglingRFC 9112 §6.1TE.CL confirmation using a chunk-size prefix trick: Content-Length covers only the chunk-size line, leaving chunk-data that begins with a GET / request. “Regardless, the server MUST close the connection after responding to such a request.”
99SMUG-DUPLICATE-CL-SMUGGLED-GETSmugglingRFC 9110 §8.6Sequence confirmation variant of duplicate Content-Length using an embedded GET / immediately after the shorter body’s boundary. “If a message is received without Transfer-Encoding and with an invalid Content-Length header field… the recipient MUST treat it as an unrecoverable error.”

SHOULD-Level Requirements (29 tests)

The RFC recommends this behavior. Valid exceptions exist but must be understood and justified.

#Test IDSuiteRFCRFC Quote
1COMP-HTTP10-DEFAULT-CLOSEComplianceRFC 9112 §9.3“HTTP implementations SHOULD support persistent connections.” HTTP/1.0 without keep-alive: server SHOULD close after response.
2COMP-LEADING-CRLFComplianceRFC 9112 §2.2“A server that is expecting to receive and parse a request-line SHOULD ignore at least one empty line (CRLF) received prior to the request-line.”
3RFC9112-3-MULTI-SP-REQUEST-LINEComplianceRFC 9112 §3“A recipient SHOULD NOT attempt to autocorrect and then process the request without a redirect, since the invalid request-line might be deliberately crafted to bypass security filters.” Multiple spaces = invalid request-line grammar.
4RFC9112-3.2-FRAGMENT-IN-TARGETComplianceRFC 9112 §3.2“Recipients of an invalid request-line SHOULD respond with either a 400 (Bad Request) error or a 301 (Moved Permanently) redirect.” Fragment (#) is not part of origin-form.
5RFC9112-2.3-HTTP09-REQUESTComplianceRFC 9112 §2.3HTTP/0.9 has no version token. “Recipients of an invalid request-line SHOULD respond with either a 400 (Bad Request) error.”
6RFC9112-2.3-INVALID-VERSIONComplianceRFC 9112 §2.3Invalid HTTP-version format. “Recipients of an invalid request-line SHOULD respond with either a 400 (Bad Request) error.” (No explicit MUST — the Requirement field says “No MUST”.)
7COMP-REQUEST-LINE-TABComplianceRFC 9112 §3Grammar: request-line = method SP request-target SP HTTP-version. SP is specifically 0x20. Tab is not SP. “A recipient SHOULD NOT attempt to autocorrect.” SHOULD reject, MAY accept.
8COMP-METHOD-TRACEComplianceRFC 9110 §9.3.8“A client MUST NOT send content in a TRACE request.” Servers SHOULD disable TRACE in production to prevent cross-site tracing (XST).
9COMP-TRACE-WITH-BODYComplianceRFC 9110 §9.3.8“A client MUST NOT send content in a TRACE request.” Server SHOULD reject TRACE with body — 400/405 preferred.
10COMP-METHOD-CONNECTComplianceRFC 9110 §9.3.6“An origin server MAY accept a CONNECT request, but most origin servers do not implement CONNECT.” Origin server SHOULD reject with 400/405/501.
11SMUG-CL-LEADING-ZEROSSmugglingRFC 9110 §8.6Content-Length = 1*DIGIT. “0005” matches the grammar but creates parser-disagreement risk (octal vs decimal interpretation). SHOULD reject.
12SMUG-CL-TRAILING-SPACESmugglingRFC 9110 §5.5OWS trimming is valid per field-value = *( field-content ). But trailing space in CL value is unusual. SHOULD be trimmed per OWS rules.
13SMUG-CL-EXTRA-LEADING-SPSmugglingRFC 9110 §5.5Extra leading whitespace (double space) as OWS. Valid per OWS = *( SP / HTAB ) but unusual. SHOULD trim.
14SMUG-CL-DOUBLE-ZEROSmugglingRFC 9110 §8.6“00” matches 1*DIGIT grammar but leading zero creates parser ambiguity. SHOULD reject — same class as CL-LEADING-ZEROS.
15SMUG-CL-LEADING-ZEROS-OCTALSmugglingRFC 9110 §8.6“0200” — octal 128 vs decimal 200. Parser disagreement vector. SHOULD reject to eliminate ambiguity.
16SMUG-TE-DOUBLE-CHUNKEDSmugglingRFC 9112 §6.1“A sender MUST NOT apply the chunked transfer coding more than once.” Duplicate chunked with CL — ambiguous. SHOULD reject.
17SMUG-TE-CASE-MISMATCHSmugglingRFC 9110 §7.8“Recipients SHOULD use case-insensitive comparison when matching each protocol-name.” “Chunked” (capital C) SHOULD be recognized.
18SMUG-TE-TRAILING-COMMASmugglingRFC 9110 §5.6.1“A sender MUST NOT generate empty list elements.” But “A recipient MUST parse and ignore a reasonable number of empty list elements.” SHOULD handle gracefully.
19SMUG-TE-LEADING-COMMASmugglingRFC 9110 §5.6.1Same — leading comma creates empty list element. “A recipient MUST parse and ignore a reasonable number of empty list elements.” SHOULD handle.
20MAL-BINARY-GARBAGEMalformedRFC 9112 §2.2“The server SHOULD respond with a 400 (Bad Request) response and close the connection.”
21MAL-LONG-URLMalformedRFC 9112 §3“A server that receives a request-target longer than any URI it wishes to parse MUST respond with a 414 (URI Too Long) status code.” (MUST for 414 specifically, but SHOULD for having a limit.)
22MAL-LONG-METHODMalformedRFC 9112 §3“A server that receives a method longer than any that it implements SHOULD respond with a 501 (Not Implemented) status code.”
23MAL-LONG-HEADER-VALUEMalformedRFC 9110 §5.4“A server that receives a request header field line, field value, or set of fields larger than it wishes to process MUST respond with an appropriate 4xx (Client Error) status code.” (MUST for 4xx, SHOULD for having a limit.)
24MAL-LONG-HEADER-NAMEMalformedRFC 9110 §5.4Same as above.
25COMP-UNKNOWN-METHODComplianceRFC 9110 §9.1“An origin server that receives a request method that is unrecognized or not implemented SHOULD respond with the 501 (Not Implemented) status code.”
26COMP-OPTIONS-ALLOWComplianceRFC 9110 §9.3.7“A server generating a successful response to OPTIONS SHOULD send any header that might indicate optional features implemented by the server and applicable to the target resource (e.g., Allow).”
27COMP-CONTENT-TYPEComplianceRFC 9110 §8.3“A sender that generates a message containing content SHOULD generate a Content-Type header field in the message.”
28COMP-LONG-URL-OKComplianceRFC 9112 §3“It is RECOMMENDED that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.” Server SHOULD accept ~7900-char path.
29COMP-DUPLICATE-CTComplianceRFC 9110 §5.3“A sender MUST NOT generate multiple header fields with the same field name.” Content-Type is not list-based — duplicate values SHOULD be rejected with 400.

MAY-Level Requirements (10 tests)

The RFC explicitly permits either behavior. Both acceptance and rejection are fully compliant.

#Test IDSuiteRFCRFC Quote
1RFC9112-2.2-BARE-LF-REQUEST-LINEComplianceRFC 9112 §2.2“A recipient MAY recognize a single LF as a line terminator and ignore any preceding CR.”
2RFC9112-2.2-BARE-LF-HEADERComplianceRFC 9112 §2.2Same — bare LF in headers. MAY accept.
3COMP-EXPECT-UNKNOWNComplianceRFC 9110 §10.1.1“A server that receives an Expect field value containing a member other than 100-continue MAY respond with a 417 (Expectation Failed) status code.”
4COMP-GET-WITH-CL-BODYComplianceRFC 9110 §9.3.1“Content received in a GET request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request.” MAY reject.
5SMUG-CHUNK-EXT-LFSmugglingRFC 9112 §2.2“A recipient MAY recognize a single LF as a line terminator.” Bare LF in chunk extension — MAY accept.
6SMUG-CHUNK-LF-TERMSmugglingRFC 9112 §2.2Same — bare LF as chunk data terminator. MAY accept.
7SMUG-CHUNK-LF-TRAILERSmugglingRFC 9112 §2.2Same — bare LF in chunked trailer termination. MAY accept.
8COMP-HTTP10-NO-HOSTComplianceRFC 9112 §3.2“A client MUST send a Host header field in all HTTP/1.1 request messages.” This requirement applies only to HTTP/1.1. HTTP/1.0 without Host is valid. MAY accept or reject.
9COMP-HTTP12-VERSIONComplianceRFC 9112 §2.3HTTP/1.2 has a higher minor version. A server MAY accept or return 505.
10MAL-CL-TAB-BEFORE-VALUEMalformedRFC 9110 §5.6.3OWS = *( SP / HTAB ). Tab is valid optional whitespace after the colon. Fully compliant — MAY accept.

“ought to” Level (1 test)

Weaker than SHOULD — recommends but does not normatively require.

#Test IDSuiteRFCRFC Quote
1SMUG-CL-TE-BOTHSmugglingRFC 9112 §6.3“Such a message might indicate an attempt to perform request smuggling… and ought to be handled as an error.” §6.1: “A server MAY reject a request that contains both Content-Length and Transfer-Encoding or process such a request in accordance with the Transfer-Encoding alone.”

Unscored Tests (51 tests)

These tests are informational — they produce warnings but never fail.

#Test IDSuiteRFCNotes
1SMUG-TRANSFER_ENCODINGSmugglingRFC 9112 §6.1Transfer_Encoding (underscore) is a valid token but not the standard header. Some parsers normalize.
2SMUG-CL-COMMA-SAMESmugglingRFC 9110 §8.6“A recipient of a Content-Length header field value consisting of the same decimal value repeated as a comma-separated list MAY either reject the message as invalid or replace that invalid field value with a single instance.”
3SMUG-CL-COMMA-TRIPLESmugglingRFC 9110 §8.6Same — three comma-separated identical CL values. Extended merge test.
4SMUG-CHUNKED-WITH-PARAMSSmugglingRFC 9112 §7“The chunked coding does not define any parameters. Their presence SHOULD be treated as an error.”
5SMUG-EXPECT-100-CLSmugglingRFC 9110 §10.1.1Expect: 100-continue with CL — standard behavior, tested for proxy interaction.
6SMUG-TRAILER-CLSmugglingRFC 9110 §6.5.1Content-Length in trailers — prohibited trailer field. MUST NOT be used for framing.
7SMUG-TRAILER-TESmugglingRFC 9110 §6.5.1Transfer-Encoding in trailers — prohibited trailer field.
8SMUG-TRAILER-HOSTSmugglingRFC 9110 §6.5.2Host in trailers — must not be used for routing.
9SMUG-TRAILER-AUTHSmugglingRFC 9110 §6.5.1Authorization in trailers — prohibited trailer field.
10SMUG-TRAILER-CONTENT-TYPESmugglingRFC 9110 §6.5.1Content-Type in trailers — prohibited trailer field.
11SMUG-HEAD-CL-BODYSmugglingRFC 9110 §9.3.2HEAD with body — server must not leave body on connection.
12SMUG-OPTIONS-CL-BODYSmugglingRFC 9110 §9.3.7OPTIONS with body — server should consume or reject body.
13SMUG-TE-TAB-BEFORE-VALUESmugglingRFC 9110 §5.5Tab as OWS before TE value — valid per OWS = *( SP / HTAB ).
14SMUG-ABSOLUTE-URI-HOST-MISMATCHSmugglingRFC 9112 §3.2.2Absolute-form URI host differs from Host header — routing confusion vector.
15COMP-ABSOLUTE-FORMComplianceRFC 9112 §3.2.2Absolute-form request-target — server MUST accept per RFC but many reject.
16COMP-METHOD-CASEComplianceRFC 9110 §9.1Methods are case-sensitive. Lowercase “get” is an unknown method. Server SHOULD respond 501.
17MAL-RANGE-OVERLAPPINGMalformedRFC 9110 §14.2“A server that supports range requests MAY ignore or reject a Range header field that contains… a ranges-specifier with more than two overlapping ranges.”
18MAL-URL-BACKSLASHMalformedN/ABackslash is not a valid URI character. Some servers normalize to /.
19NORM-CASE-TENormalizationN/AAll-uppercase TRANSFER-ENCODING — tests header name case normalization.
20COMP-TRACE-SENSITIVEComplianceRFC 9110 §9.3.8“A server SHOULD exclude any request header fields that are likely to contain sensitive data.” TRACE with Authorization header — checks if secret is echoed.
21COMP-ACCEPT-NONSENSEComplianceRFC 9110 §12.5.1Unrecognized Accept value — server may return 406 or serve default representation. Both behaviors valid.
22COMP-DATE-FORMATComplianceRFC 9110 §5.6.7“A sender MUST generate timestamps in the IMF-fixdate format.” Checks Date header format.
23COMP-RANGE-INVALIDComplianceRFC 9110 §14.2“A server MAY ignore the Range header field.” Invalid Range syntax — 2xx or 416 both acceptable.
24COMP-POST-UNSUPPORTED-CTComplianceRFC 9110 §15.5.16POST with unknown Content-Type — 415 or 2xx both acceptable.
25SMUG-PIPELINE-SAFESmugglingRFC 9112 §9.3Baseline: two clean pipelined GETs. Validates sequence test infrastructure against the target.
26SMUG-CL0-BODY-POISONSmugglingRFC 9112 §6.2Content-Length: 0 plus trailing bytes, then follow-up GET on same socket. Sequence telemetry for 0.CL-style poisoning behavior.
27SMUG-GET-CL-BODY-DESYNCSmugglingRFC 9110 §9.3.1“Content received in a GET request … might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack.” Adds follow-up desync check.
28SMUG-OPTIONS-CL-BODY-DESYNCSmugglingRFC 9110 §9.3.7OPTIONS with body plus follow-up GET to detect unread-body poisoning on persistent connections.
29SMUG-EXPECT-100-CL-DESYNCSmugglingRFC 9110 §10.1.1Expect/continue flow with immediate body plus follow-up GET; highlights whether connection framing remains synchronized.
30SMUG-GET-CL-PREFIX-DESYNCSmugglingRFC 9110 §9.3.1GET with a body containing an incomplete request prefix (missing the blank line). The follow-up write completes it and then sends a normal GET. If multiple responses are observed on step 2, the prefix bytes were likely left unread and executed.
31CAP-ETAG-304CapabilitiesRFC 9110 §13.1.2ETag conditional GET — server should return 304 when If-None-Match matches. Caching support is optional.
32CAP-LAST-MODIFIED-304CapabilitiesRFC 9110 §13.1.3Last-Modified conditional GET — server should return 304 when If-Modified-Since matches. Caching support is optional.
33CAP-ETAG-IN-304CapabilitiesRFC 9110 §15.4.5Checks whether 304 responses include the ETag header, allowing clients to update cached validators.
34CAP-INM-PRECEDENCECapabilitiesRFC 9110 §13.1.2If-None-Match must take precedence over If-Modified-Since when both are present.
35CAP-INM-WILDCARDCapabilitiesRFC 9110 §13.1.2If-None-Match: * on an existing resource should return 304 (wildcard matches any representation).
36CAP-IMS-FUTURECapabilitiesRFC 9110 §13.1.3If-Modified-Since with a future date must be ignored — server should return 200, not 304.
37CAP-IMS-INVALIDCapabilitiesRFC 9110 §13.1.3If-Modified-Since with a garbage (non-HTTP-date) value must be ignored — server should return 200.
38CAP-INM-UNQUOTEDCapabilitiesRFC 9110 §8.8.3If-None-Match with an unquoted ETag violates entity-tag syntax — server should return 200, not 304.
39CAP-ETAG-WEAKCapabilitiesRFC 9110 §13.1.2Weak ETag comparison for GET If-None-Match — server must use weak comparison and return 304.
40COOK-ECHOCookiesRFC 6265 §5.4Baseline — confirms /echo endpoint reflects Cookie header.
41COOK-OVERSIZEDCookiesRFC 6265 §6.164KB Cookie header — tests header size limits on cookie data. 400/431 or 2xx both acceptable.
42COOK-EMPTYCookiesRFC 6265 §4.2Empty Cookie value — tests parser resilience on empty cookie-string.
43COOK-NULCookiesRFC 9110 §5.5NUL byte in cookie value — dangerous if preserved by parser.
44COOK-CONTROL-CHARSCookiesRFC 6265 §4.1.1Control characters (0x01-0x03) in cookie value — not valid cookie-octets.
45COOK-MANY-PAIRSCookiesRFC 6265 §6.11000 cookie pairs — tests parser performance limits.
46COOK-MALFORMEDCookiesRFC 6265 §4.1.1Completely malformed cookie syntax (===;;;) — tests crash resilience.
47COOK-MULTI-HEADERCookiesRFC 6265 §5.4Two separate Cookie headers — should be folded per RFC 6265.
48COOK-PARSED-BASICCookiesRFC 6265 §4.1.1Single cookie parsed by framework.
49COOK-PARSED-MULTICookiesRFC 6265 §4.2.1Three cookies parsed from semicolon-delimited header.
50COOK-PARSED-EMPTY-VALCookiesRFC 6265 §4.1.1Cookie with empty value — *cookie-octet allows zero or more.
51COOK-PARSED-SPECIALCookiesRFC 6265 §4.1.1Spaces and = in cookie values — edge cases for parser splitting.

N/A — Best-Practice / Defensive Tests (11 tests)

These tests don’t map to a single RFC 2119 keyword but enforce defensive best practices.

#Test IDSuiteRFCRFC Quote / Rationale
1COMP-BASELINEComplianceN/ASanity check — valid GET must return 2xx.
2MAL-MANY-HEADERSMalformedRFC 6585 §5“The 431 status code indicates that the server is unwilling to process the request because its header fields are too large.” Server should enforce header count limits.
3MAL-INCOMPLETE-REQUESTMalformedRFC 9112 §2.2Grammar not matched — server SHOULD respond 400 and close. Timeout also acceptable.
4MAL-EMPTY-REQUESTMalformedRFC 9112 §2.2Zero bytes — no grammar match possible. 400, close, or timeout acceptable.
5MAL-WHITESPACE-ONLY-LINEMalformedRFC 9112 §2.2Whitespace-only request line — not an empty line (CRLF) and not a valid request-line.
6MAL-H2-PREFACEMalformedRFC 9113 §3.4HTTP/2 preface on HTTP/1.1 port — protocol confusion. 400/505/close/timeout acceptable.
7MAL-URL-PERCENT-NULLMalformedRFC 9110 §5.5Percent-encoded NUL (%00) — null byte injection risk. 400 = pass, 2xx/404 = warn.
8MAL-URL-PERCENT-CRLFMalformedRFC 9110 §5.5Percent-encoded CRLF (%0d%0a) — header injection if decoded during parsing. 400 = pass, 2xx/404 = warn.
9MAL-CHUNK-EXT-64KMalformedRFC 9112 §7.1.1“A server ought to limit the total length of chunk extensions.” (CVE-2023-39326 class.)
10NORM-UNDERSCORE-CLNormalizationN/AContent_Length — valid token but dangerous if normalized to Content-Length. Drop or reject = pass.
11NORM-UNDERSCORE-TENormalizationN/ATransfer_Encoding — same class of normalization attack. Drop or reject = pass.

Requirement Level by Suite

Compliance Suite (76 tests)

LevelTests
MUST47
SHOULD15
MAY6
Unscored7
N/A1

Smuggling Suite (87 tests)

LevelTests
MUST54
SHOULD9
MAY3
“ought to”1
Unscored20

Malformed Input Suite (26 tests)

LevelTests
MUST10
SHOULD5
MAY1
Unscored2
N/A8

Normalization Suite (5 tests)

LevelTests
MUST2
Unscored1
N/A2

Capabilities Suite (9 tests)

LevelTests
Unscored9

Cookies Suite (12 tests)

LevelTests
Unscored12

RFC Section Cross-Reference

RFC SectionTestsTopic
RFC 9112 §2.214Line endings, bare CR/LF, message parsing
RFC 9112 §2.36HTTP version
RFC 9112 §39Request line, method, request-target
RFC 9112 §3.211Host header, request-target forms
RFC 9112 §57Header field syntax, sp-before-colon
RFC 9112 §5.24Obsolete line folding
RFC 9112 §6.129Transfer-Encoding, CL+TE ambiguity
RFC 9112 §6.25Content-Length body framing
RFC 9112 §6.35Message body length determination
RFC 9112 §7.118Chunked transfer coding format
RFC 9112 §7.1.15Chunk extensions
RFC 9112 §7.1.21Chunked trailer section
RFC 9112 §9.3-9.63Connection management
RFC 9110 §5.31Header field duplication
RFC 9110 §5.4-5.68Field limits, values, lists, tokens
RFC 9110 §6.6.11Date header
RFC 9110 §7.21Host header semantics
RFC 9110 §7.85Upgrade
RFC 9110 §8.31Content-Type
RFC 9110 §8.615Content-Length semantics
RFC 9110 §9.1-9.313Methods (GET, HEAD, CONNECT, OPTIONS, TRACE)
RFC 9110 §10.1.13Expect header
RFC 9110 §6.55Trailer field restrictions
RFC 9110 §12.5.11Content negotiation (Accept)
RFC 9110 §13.14Conditional requests (ETag, If-None-Match, If-Modified-Since)
RFC 9110 §14.23Range requests
RFC 9110 §15.211xx status codes
RFC 9110 §15.4.51304 Not Modified response requirements
RFC 9110 §15.5.61405 Method Not Allowed
RFC 9110 §15.5.161415 Unsupported Media Type
RFC 64552WebSocket handshake
RFC 65853431 status code
RFC 36291UTF-8 encoding
RFC 91131HTTP/2 preface
RFC 626512Cookie handling
N/A7Best practice / defensive
RFC Basics