First, thank you for creating Http11Probe. Amazing. Holy cow!
I ran into a small edge case with the test MAL-POST-CL-HUGE-NO-BODY.
The test sends a POST request with a huge Content-Length (999999999) but no body, and expects the server to respond with 400, close, or timeout.
My server handles this by immediately rejecting the request with 413 Content Too Large (and then closing the connection) when it sees the Content-Length header exceeds the configured limit, without waiting for the body.
However, the tool marks this as a failure because it expects status code 400:
"id": "MAL-POST-CL-HUGE-NO-BODY",
"expected": "400/close/timeout",
"verdict": "Fail",
"statusCode": 413,
"rawRequest": "POST / HTTP/1.1\r\nHost: 127.0.0.1:<PORT>\r\nContent-Length: 999999999\r\n\r\n",
"rawResponse": "HTTP/1.1 413 Content Too Large\r\nConnection: close\r\n\r\n"
Proposal
I'd like to suggest expanding the expected success conditions for MAL-POST-CL-HUGE-NO-BODY to include status code 413.
Rationale
According to RFC 9110 §15.5.14:
The 413 (Content Too Large) status code indicates that the server is refusing to process a request because the request content is larger than the server is willing or able to process.
While 400 Bad Request is a valid catch-all for malformed input, 413 is more semantically specific and correct when the server rejects a request based on the size indicated by the Content-Length header. Returning 413 and then closing the connection fulfills the spirit of the test (preventing resource exhaustion) while being highly spec-compliant.
Would you be open to adding 413 to the list of acceptable status codes for this test?
Thanks so much!
First, thank you for creating Http11Probe. Amazing. Holy cow!
I ran into a small edge case with the test
MAL-POST-CL-HUGE-NO-BODY.The test sends a
POSTrequest with a hugeContent-Length(999999999) but no body, and expects the server to respond with400,close, ortimeout.My server handles this by immediately rejecting the request with
413 Content Too Large(and then closing the connection) when it sees theContent-Lengthheader exceeds the configured limit, without waiting for the body.However, the tool marks this as a failure because it expects status code
400:Proposal
I'd like to suggest expanding the expected success conditions for
MAL-POST-CL-HUGE-NO-BODYto include status code413.Rationale
According to RFC 9110 §15.5.14:
While
400 Bad Requestis a valid catch-all for malformed input,413is more semantically specific and correct when the server rejects a request based on the size indicated by theContent-Lengthheader. Returning413and then closing the connection fulfills the spirit of the test (preventing resource exhaustion) while being highly spec-compliant.Would you be open to adding
413to the list of acceptable status codes for this test?Thanks so much!