I am not creating a new node; I am trying to extend the ones for Websocket such that a header is passed before making a ws connection.
For my particular requirement, I want to read a file and set its content as a header value before the ws connection happens. So, in 22-websocket.js, before new ws(), I added the following.
var someFile = path.join("/tmp", "something")
if (fs.existsSync(someFile)) {
var someData = fs.readFileSync(someFile)
options.header = {
"someHeader": someData
}
}
The npm test fails as shown below. Can you please advise?
websocket Node
websocket-listener
✓ should load
✓ should be server
✓ should handle wholemsg property
✓ should create socket
✓ should close socket on delete
✓ should receive data
✓ should receive wholemsg
✓ should receive wholemsg when data not JSON
✓ should receive wholemsg when data not object
(node:4212) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 upgrade listeners added to [Server]. Use emitter.setMaxListeners() to increase limit
(Use `node --trace-warnings ...` to show where the warning was created)
✓ should send
✓ should send wholemsg
✓ should do nothing if no payload (108ms)
✓ should echo
✓ should echo wholemsg
✓ should broadcast
websocket-client
Fatal error: Cannot read property 'should' of null
Can't really tell from that test output what is going on. It would be easier probably if you put some console.log output into the code. A link to the original core code would also be helpful - it is a pain to find otherwise
I assume that you are aware that custom headers are only allowed on a ws connection at the initial handshake? Once the connection upgrades to ws, no custom headers are passed.
This is the link to the source code. (Should have pasted earlier!)
I assume that you are aware that custom headers are only allowed on a ws connection at the initial handshake? Once the connection upgrades to ws, no custom headers are passed.
The implementation of Websocket nodes uses the wsnpm module. And, I am passing options.headers object when ws is created. See here for more details.
Makes no difference, the lack of custom headers past the initial handshake phase is a websockets standard issue. You can find the details on the ws RFC.
I would think that it would be better to change the core node to allow the passing in of options via an incoming msg. Trying to add your specific requirement to a core node is likely to be very hard to maintain. Whereas allowing options to be passed in would be generally usable for anyone and could be included as an update to Node-RED itself.
The header will still only be available on the initial connection still though.