net/http: missing CRLF in response body when rejecting syntactically malformed requests

[jfrech]

Go version

go1.23.4

Output of go env in your module/workspace:

https://cs.opensource.google/go/go/+/refs/tags/go1.23.4:src/net/http/server.go;l=2058

What did you do?

My web server lies atop Go's *net/http.Server. When fiddling with a new endpoint, I had a truly baffling cURL session:

$ curl jfrech.com -H "x:y$(echo -e '\r\n')"
400 Bad Request$

(Note the missing newline before the final $.)

Somehow, a shell variable in my session must have gotten infected with a trailing CRLF which cURL seems to blindly stick into its request (I would have expected cURL to error or sanitize it away; or even (try to) encode the CRLF.)

What did you see happen?

Even stranger, no logs whatsoever where written server-side and my cURL request felt like it was never experienced by my web server. A strangely missing newline was the cherry on top.

What did you expect to see?

I think https://cs.opensource.google/go/go/+/refs/tags/go1.23.4:src/net/http/server.go;l=2058 [2024-12-11] is missing a final CRLF.

Cursorily glancing at the surrounding code, the addition of a trailing CRLF also wouldn't hurt the four preceding fmt.Fprintf lines.

[gabyhelp]

Related Issues

• net/http: discrepancy in CRLF termination in http messages #53186
• net/http: Server and ReadRequest not requiring CRLF to end request-line and headers #19106 (closed)
• affected/package: net/http #56835 (closed)
• net/http: Chunked request body incorrectly terminated on `\r\n\r\n` instead of `0\r\n\r\n` #64517 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[cagedmantis]

cc @neild

[seankhliao]

According to RFC 7230 https://datatracker.ietf.org/doc/html/rfc7230#section-3 a CRLF is neither expected no necessary after the end of the body.