In the Node.JS docs for HTTP (v0.8.20), under ServerRequest, I see events for data and end. I do not see an event for error.
Normally, if there was an interruption while receiving data, I could detect it by looking at error. But will that work for postdata?
How can I be sure whether have received the entire postdata, and that it was not truncated due to network failure?
I have not confirmed this with actual running code, but just looking at the manual, http.ServerRequest is a Readable Stream and that has Event: 'error' documented.
there's been a recent issue on this: https://github.com/joyent/node/pull/4775
in general, you should always listen for and handle errors from any streams and eventemitters
Related
I had hard time debugging a problem with my NodeJS' code today.
I have problems when I open two connections to the same unix socket (reasons though); and for unknown reasons, sometimes it works fine throughout; and sometimes I don't get back any data, but connect is fired for only one of them.
I'm still trying to debug, but I deep dived into documentation and faced another question. As NodeJS Docs (12.x LTS) states: (about net.Socket)
# Event: 'connect'
Added in: v0.1.90
Emitted when a socket connection is successfully established. See net.createConnection().
# Event: 'ready'
Added in: v9.11.0
Emitted when a socket is ready to be used. Triggered immediately after 'connect'.
(https://nodejs.org/docs/latest-v12.x/api/net.html)
I wondered if that is where I should look for error:
what does immediately mean? Does it mean synchronously? If so, is there any difference between ready and connect?
is there any point for one using ready instead of connect for doing after-connection-established/opened tasks?
what is the difference between the two?
Thanks!
This event is emitted from net for consistency across different APIs. See the original commit here:
https://github.com/nodejs/node/commit/1c8149417a5dec9b2af056f306822b8a22a09706
It was created to make developers' life easier when working with fs and net code, so that they don't have to remember all the intricate details of a given stream implementation.
In practice, the Node.js socket code does this:
self.emit('connect');
self.emit('ready');
I'm piping a CCTV stream using request, and serve it using Express.
Sometimes there is problem with network connection in the middle of streaming, that cause in the client picture freeze on the last chunked data.
I need to catch this event so I can manipulate on the client by serve some-error image file. I tried exit, close, finish, stop events but none success.
So far I didn't found similar problem on request's Issues or on other SO questions.
Sorry for being late,
I figure out that passing timeout option can catch network disconnection and trigger error event. It printed as Error: ESOCKETTIMEDOUT.
This is quite enough for my needs.
My HTTP server needs to make sure that HTTP responses are delivered to the client.
I feel (and I will implement it so) that the most correctly way is to send the "I received the data" request from the client.
But I have a bit academic question:
Has the server some other means to detect whether the response delivered to the client or not (say due to the client's computer was evaporated by a direct hit of an H-bomb during data transmission)?
According to the node.js http documentation:
Class: http.ServerResponse
...
Event: 'finish'
Emitted when the response has been sent. More specifically, this event
is emitted when the last segment of the response headers and body have
been handed off to the operating system for transmission over the
network. It does not imply that the client has received anything yet.
After this event, no more events will be emitted on the response
object.
Also I did not find nothing better in the 'net' module documentation.
So it seems I can only know that my data is in the kernel buffer for transmisstion over the network.
Can I detect some errors at this transmission by Node.js means?
Can I detect some errors at this transmission by some easy-to-implement non-Node.js means?
Any links and thoughts that this is not an HTTP way or even not a TCP way are also appreciated.
The thing about TCP is that the receiver must acknowledge the fact that it receives every single bit of data. If that's not the case, sender keeps sending the pieces of data that receiver has not yet acknowledged to receive.
I checked out the Net module and I saw this interesting piece:
Event: 'end'
#
Added in: v0.1.90
Emitted when the other end of the socket sends a FIN packet.
I have no implementation idea for this but still, this might be useful for your case.
I have a net stream that I want to use, however I can't use it directly due to the CORS limitation and that EventSource doesn't support authentication ..
I want to use node.js to get the stream from the source (domainA) and relay it to the requester.
so the flow would be: domainA --> node.js --> client
I was using https.request to get the data, but the thing is that its closing the connection after the first time.
so my question is - how would I proper implement this on node.js? how do I keep the connection alive and the data coming?
I was actually able to resolve this myself. what I was trying to do is simply 'mirror' an event source due to CORS restrictions. the connection kept closing after the first request, I found out that I was actually sending the wrong headers. After sending "Accept": "text/event-stream" the connection was kept opened and the data flowing. Thanks anyway!
I have an application which writes to a datastore, so I attempt to send an HTTP request out to the datastore (hbase + stargate). ETIMEDOUT exception, which kills the process.
I have .on('error') on every socket connection present or at least seemingly present, including requests and responses. I even took an extreme step and make a change to the source code, which is supposed to "ignore" those errors in the third post:
http://comments.gmane.org/gmane.comp.lang.javascript.nodejs/25283
I even have a
process.on('uncaughtException', function(){})
All of this still to no avail, and my processes keep dying. Potentially losing everything that built up in the ZMQ stream queue.
The weirdest part yet is that one server out of the 4 server cluster, behaves just fine.
I had a like-issue with our datastore that relied on HTTP requests.
How are you sending the "HTTP request out"? Is it with a library? Have you tried putting a timeout limit on the HTTP request to avoid the ETIMEDOUT exception? Although this does not address the main issue, it will give you the ability to catch the timeout by throwing your own controlled exception.