This adds the following to HTTP:
* server.setTimeout(msecs, callback)
Sets all new connections to time out after the specified time, at
which point it emits 'timeout' on the server, passing the socket as an
argument.
In this way, timeouts can be handled in one place consistently.
* req.setTimeout(), res.setTimeout()
Essentially an alias to req/res.socket.setTimeout(), but without
having to delve into a "buried" object. Adds a listener on the
req/res object, but not on the socket.
* server.timeout
Number of milliseconds before incoming connections time out.
(Default=1000*60*2, as before.)
Furthermore, if the user sets up their own timeout listener on either
the server, the request, or the response, then the default behavior
(destroying the socket) is suppressed.
Fix#3460
http.ServerRequest and http.ClientResponse are merged into http.IncomingMessage
which has fields for both, and acts as a Readable Stream and EventEmitter.
Fixes#3851.
* The 'close' event doesn't emit an error object.
* It's possible for a 'close' event to come after an 'end' event, contrary to
what the documentation said.
Fixes#4116.
Listen for the 'clientError' event that is emitted when a renegotation attack
is detected and close the connection.
Fixes test/pummel/test-https-ci-reneg-attack.js
This reverts commit 790d651f0d.
This makes Duplex streams unworkable, and would only ever be a special
case for HTTP responses, which is not ideal.
Intead, we're going to just bless the 'finish' event for all Writable
streams in 0.10
This implements server.listen({ fd: <filedescriptor> }). The fd should
refer to an underlying resource that is already bound and listening, and
causes the new server to also accept connections on it.
Not supported on Windows. Raises ENOTSUP.
This is an incredibly useful thing to know about, and it
will likely never change. I can't remember why we
didn't ever document it, and people keep suggesting we
do so.