As RFC 2616 says we should, assume that servers will provide a persistent
connection by default.
> A significant difference between HTTP/1.1 and earlier versions of
> HTTP is that persistent connections are the default behavior of any
> HTTP connection. That is, unless otherwise indicated, the client
> SHOULD assume that the server will maintain a persistent connection,
> even after error responses from the server.
> HTTP/1.1 applications that do not support persistent connections MUST
> include the "close" connection option in every message.
Fixes#2436.
With Upgrade or CONNECT request, http.ClientRequest emits 'close' event
after its socket is closed. However, after receiving a response, the socket
is not under management by the request.
http.ClientRequest should detach the socket before 'upgrade'/'connect'
event is emitted to pass the socket to a user. After that, it should
emit 'close' event immediately without waiting for closing of the socket.
Fixes#2510.
http2.js
protocols object to store defaults for http and https, and use as a switch for supported protocols.
options.hostname > options.host > 'localhost'
if I have an options.auth element and I do not have an Authorization header, I do basic auth.
http.request collapses to new ClientRequest since the defaults are handled by the protocol object
test-http-url.parse*
Fixes#1390
Conflicts:
lib/http2.js
During write(), _hasBody is checked to make sure a body
is allowed -- this is now also checked during end(body)
when write() isn't used.
Concise final chunk for HEAD req's res.end(data).
Instead of simply clearing data, check _hasBody
earlier to avoid sending cruft when chunkedEncoding
is used.
Fixes#1291.
For classes defined in the module, this is fine. For 'Error'
it's probably not very hazardous. However, testing 'Object'
and 'String' is much more reliable using typeof, to work with
the repl and NODE_MODULE_CONTEXT modes.