fix: pass user-defined http(s) agent to websocket methods#953
fix: pass user-defined http(s) agent to websocket methods#953
Conversation
Codecov Report
@@ Coverage Diff @@
## master #953 +/- ##
===========================================
- Coverage 78.57% 64.28% -14.29%
===========================================
Files 2 2
Lines 14 14
Branches 3 3
===========================================
- Hits 11 9 -2
- Misses 3 4 +1
- Partials 0 1 +1
Continue to review full report at Codecov.
|
dpopp07
force-pushed
the
support-agent-websocket
branch
2 times, most recently
from
efc4954 to
2617f4c
Compare
| null, | ||
| options.headers, | ||
| null, | ||
| requestOptions, |
There was a problem hiding this comment.
I guess the change here is based on https://github.com/theturtle32/WebSocket-Node/blob/master/docs/WebSocketClient.md#connect-using-a-proxy-server
There was a problem hiding this comment.
Yep, that's correct!
germanattanasio
left a comment
germanattanasio
left a comment
There was a problem hiding this comment.
I have used the axios agent option but never the websocket one. This looks good.
dpopp07
force-pushed
the
support-agent-websocket
branch
from
2617f4c to
cbb0cef
Compare
dpopp07
force-pushed
the
support-agent-websocket
branch
from
cbb0cef to
2840d71
Compare
## [4.5.1](v4.5.0...v4.5.1) (2019-09-19) ### Bug Fixes * pass user-defined http(s) agent to websocket methods ([#953](#953)) ([4f1679c](4f1679c))
|
🎉 This PR is included in version 4.5.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
4 participants
We accept
axiosoptions in the constructor to give the user extended control over their requests but we didn't translate this control over to the WebSocket requests. This PR doesn't give complete control over the WebSocket configuration but it allows the use of custom "agents" which will allow users to use WebSockets behind corporate proxies (an established use case).