HTTP/1.1 responses w/o Content-Length or Transfer-Encoding

[mnot]

Fixes isssue noted on list; HTTP/1.1 responses that don't have Content-Length or Transfer-Coding cause a parse error.

See:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 (#5)
... and its successor-in-the-making:
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-12#section-3.3 (#6)

[ry]

This breaks the test on "HTTP/1.1 404 Not Found\r\n\r\n"

https://github.com/ry/http-parser/blob/047ced37841b7f42b9254bce2b2e5e6b95cb7ef8/test.c#L635-648

Which I'm unclear the origin of. Should this message cause an error?

[mnot]

That message is delimited by EOF, as is "301 no response phrase". Both should have message_complete_on_eof = TRUE.

Once they're fixed, however, test_multiple3 falls down with
*** Parser didn't see 3 messages only 2 ***

The tests here are pretty intertwined, so I'm not sure how to address that; I'm guessing that they're written assuming that those responses (or similar ones) can be kept alive.

Also, the semantics of http_should_keep_alive are a bit out of whack, because you can't really keep alive a response that's delimited by EOF. Not sure if it's worth fixing, though, because AFAICT that case is never reached in the current code.

[ry]

Mark, please review this patch: https://github.com/ry/http-parser/commit/fffa54f1111bdb0ea03026220b4ef62da421fe4f

[ry]

Actually that patch I gave is breaking the 100-continue test in NodeJS. Gr.

[mnot]

Trying to page this back in; is it just the test cases that's holding it up?

[ry]

yes - test cases failing. sorry for delay

[pgriess]

We're hitting this as well. @ry I think the patch you sent out is missing the logic for responses that are mandated not to have a body (100-continue, HEAD responses, 204, 304, etc). I'll throw up a pull request today or tomorrow.

[pgriess]

Closing, as I believe this was fixed by #72. Mark, please re-open if you disagree.

[koichik]

Oops, sorry, I did not notice this.