Extra CRLF after body

[artur-ma]

Context: #856
found that the issue, is that extra CRLF that undici sends, is expected to be included in Content-Length value

Trying to understand this doc
https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html

while looking on this code

https://github.com/nodejs/undici/blob/main/lib/client.js#L1430

there is extra CRLF after writing the body

    socket.cork()
    socket.write(`${header}content-length: ${contentLength}\r\n\r\n`, 'ascii')
    socket.write(body)
    socket.write('\r\n', 'ascii')
    socket.uncork()

Is there a reason for the extra CRLF here at the end?

according to the doc

     generic-message = start-line
                      *(message-header CRLF)
                      CRLF
                      [ message-body ]
    start-line      = Request-Line | Status-Line

"In the interest of robustness, servers SHOULD ignore any empty line(s) received where a Request-Line is expected. In other words, if the server is reading the protocol stream at the beginning of a message and receives a CRLF first, it should ignore the CRLF."

so the extra CRLF that comes after the body should be ignored on the server?

but at the other hand, the doc says:

"Certain buggy HTTP/1.0 client implementations generate extra CRLF's after a POST request. To restate what is explicitly forbidden by the BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an extra CRLF."

Thanks

[mcollina]

@indutny wdyt? I know this is not parsing, but you are likely the most expert between us on this topic.

[indutny]

Yeah, you definitely don't want to send the extra CRLF after the request. llhttp should be capable of parsing it properly, but this is not quite correct encoding of the HTTP request.