-
-
Notifications
You must be signed in to change notification settings - Fork 662
feat: EventSource can be configured with reconnectionTime #4260
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this doesn't seem to be spec compliant?
The dispatch option is also not spec compliant |
I don't think we should add these kind of features. |
In smee-client we use the |
After reading through whatwg/html#2177, I am a +1 on adding this in a different capacity. Like WebSocket, browsers (mostly Chrome) have seemingly given up on EventSource and have held back improvements on it. I recommend the option being put under an This also would needs docs and tests. new EventSource('https://my.event.source/', { node: { reconnectionTime: 0 } }) |
I consider adding this to fetch/WebSocket a mistake. It should have been namespaced, like Cloudflare does with custom options. https://developers.cloudflare.com/workers/runtime-apis/request/#the-cf-property-requestinitcfproperties |
We could add the namespaced one and deprecate the previous one in the next release (maybe major?). |
That sounds great to me. I think it drastically reduces confusion and allows us to add whatever we want in the future, without having to regard conflicts with upcoming spec additions or other environments (ie. Deno has a "client" option which functions similarly to our "dispatcher" option, yet neither are compatible). WebSocket is a slightly different issue as passing a plain object to the constructor is a deviation from the spec in and of itself already. We could recommend the following, which would function in all environments, but is an objectively terrible solution. const options = ['protocols']
options.headers = { 'Authorization': 'Bearer 123456' }
options.dispatcher = ...
// with the new namespaced options:
options.node = {
headers: { 'Authorization': 'Bearer 123456' },
dispatcher: ...
}
const ws = new WebSocket('ws://localhost:1', options) Currently we allow const ws = new WebSocket('ws://localhost:1', {
protocols: ['protocols'],
headers: { 'Authorization': 'Bearer 123456' },
dispatcher: ...
}) but I think I am getting off topic now, so I digress. I spared you my rant about Chrome holding up the websocket spec, you're welcome. 😂 |
…cate dispatcher attribute on top level
11d3380
to
0254706
Compare
Is this to your liking? :) |
Yes but there seem to be related test failures |
Now runs through. |
@mcollina PTAL |
Integrate SOCKS5 proxy support into the existing ProxyAgent class: - Add SOCKS5 protocol detection (socks5: and socks: schemes) - Use Socks5ProxyWrapper for SOCKS5 connections instead of HTTP CONNECT - Properly handle SOCKS5 proxy lifecycle (no proxy client needed) - Pass through authentication credentials to SOCKS5 wrapper - Disable CONNECT tunneling for SOCKS5 proxies This completes Phase 2 of the SOCKS5 implementation. Note: Current implementation has architectural limitation requiring Pool dispatcher instead of Client for proper connection lifecycle management. Resolves: #4260
PTAL. I think the test is now reasonable. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
Tests can be implemented if #4247 is merged