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.
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.
Problem: It was not possible to detect the reason for a premature
connection termination in http requests.
This patch provides a new `err` argument to the 'close' event which
can be inspected to differentiate between a timeout and a client
actively terminating the connection.
Also contains tests for this new behavior for http and https.
However, this test is failing for some quite unrelated issue.
Getting some odd "socket hangup" crashes, and only the first request
ever makes it to the server.