Always skip body for 1xx, 204, and 304 responses

[azaretsky]

https://tools.ietf.org/html/rfc7230#section-3.3.3:
... any response with a 1xx (Informational), 204 (No Content), or 304 (Not Modified) status code is always terminated by the first empty line after the header fields, regardless of the header fields present in the message, and thus cannot contain a message body.

Fixes: #251

[bnoordhuis]

While the change LGTM in general I'm kind of worried it might break existing http-parser consumers due to the change in behavior.

[bnoordhuis]

See #363, it's possible someone might be relying on the current behavior.

[azaretsky]

This PR only changes the tests for 101 responses. The HTTP_200_RESPONSE_WITH_UPGRADE_HEADER* tests are unaffected (and they all pass).

RFC 7230 explicitly forbids using Content-Length or Transfer-Encoding in 1xx responses ("A server MUST NOT send" etc.) and RFC 2616 also had similarly strict requirements ("All 1xx ... responses MUST NOT include a message-body"), so I think it would probably be ok.

[azaretsky]

It's quite hard to tell if this behavior change will affect anyone since it seems that these responses are rarely encountered in the wild if at all: 1xx, 204, and 304 responses without a declared message body length are already correctly handled by the parser, while 1xx and 204 with a message body are not legitimate according to the spec, and real servers often do not include content-length or transfer-encoidng in 304 responses (at least IIS, nginx and apache httpd don't).

So there's a great chance that this change is harmless but also purely cosmetic and no-one actually needs it.

[bnoordhuis]

cc @indutny - perhaps you can weigh in?

[indutny]

I think it might be too hard to propagate description this change to the consumers of http-parser. In order to properly do it, we'll have to do major release.

@nodejs/http : do we consider major release a possibility, or would we prefer to stick with llhttp and do majority of changes there instead?

[azaretsky]

Just for the record: I will try to keep this branch rebased on top of the current master in case anyone wants to use it before the next major release.