Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keep-Alive ignored for HTTP(S) HEAD requests #12396

Closed
Limess opened this issue Apr 13, 2017 · 3 comments
Closed

Keep-Alive ignored for HTTP(S) HEAD requests #12396

Limess opened this issue Apr 13, 2017 · 3 comments
Labels
http Issues or PRs related to the http subsystem.

Comments

@Limess
Copy link

Limess commented Apr 13, 2017

Version: v.4.8.0, v7.9.0
Platform: OSX 10.10.5 (Darwin MC-S103314.local 14.5.0 Darwin Kernel Version 14.5.0: Sun Sep 25 22:07:15 PDT 2016; root:xnu-2782.50.9~1/RELEASE_X86_64 x86_64)
Subsystem: http / net

http(s) HEAD requests don't obey Keep-Alive, even when Connection: Keep-Alive is set.
The same http(s) GET request obeys Keep-Alive.

I believe I've followed this down to:

  1. parser->flags & F_SKIPBODY) { /* response to a HEAD request */
    which is called from
  2. return !http_message_needs_eof(parser);
    this propagates back to
  3. function parserOnHeadersComplete(versionMajor, versionMinor, headers, method,
    with shouldKeepAlive set to false, regardless of a Connection: Keep-Alive header.

I've been unable to find anything in any linked RFC from the above code block to support this being per-specification, if it is I'd appreciate someone highlighting it to me.

@Fishrock123 Fishrock123 added the http Issues or PRs related to the http subsystem. label Apr 13, 2017
@Trott
Copy link
Member

Trott commented Aug 2, 2017

@nodejs/http

@dougwilson
Copy link
Member

I don't know the history here, but I have seen similar behavior in other clients as well, with some documentating that the reason to close after a HEAD request is to interop with misbehaving servers that may send a body in the response.

@bnoordhuis
Copy link
Member

@dougwilson is spot on. The current behavior was implemented in 2011 in commit e576d4e.

I'll close this out because I don't think we want to change it. It would probably do more bad than good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
http Issues or PRs related to the http subsystem.
Projects
None yet
Development

No branches or pull requests

5 participants