HTTP/1.1 200 OK\r\n\r\n

Unless this is a response to a HEAD request, http-parser cannot determine the length of the body. So, it should read until EOF. (It does not match .1-4 of sec 4.4, then .5 is applied.)

This was making the parser to close the connection for every message without a body

You should respond with 204 No Content, not 200.

Thanks, but like @koichik said, it's not possible to determine the response body's size so there is no alternative but to read until EOF.

The 'single-line response to a HEAD request' case doesn't set the keep-alive flag right now because the parser doesn't know that it's a response to a HEAD request. I suppose that could be fixed (probably not easily) and it should be sufficiently uncommon that it's a minor optimization at best.

@bnoordhuis - If on_headers_complete() returns 1, then F_SKIPBODY flag is set. It indicates that it is a response to a HEAD request.

I'm not talking about HEAD requests.
A response to a GET, POST,... can be without a body. If there is no content-length nor transfer-encoding and no connection: close headers then response has no body and the parser should consider should be done (message_complete) after the headers and should not try to read a body until EOF.

http://tools.ietf.org/html/rfc2616#section-4.4 5.

If you think about it's pretty consistent because the client shouldn't close the connection (and the server don't expect the client to) if there is no connection: close header.

@koichik: You're right. So much the better.

@gwik: See #72. The 'read until EOF if no Content-Length' behaviour was added in response to real-world scenarios.

What I suggested was in complement to that, but reading other parts of the RFC, I realize it doesn't matter. The scenario I was describing shouldn't happen if the server follows the RFC. I just need to change my test cases.

Sorry to have bothered you about it and thank you for this great parser.