Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

Uzlopak
Copy link
Contributor

@Uzlopak Uzlopak commented Jun 4, 2025

Tests can be implemented if #4247 is merged

Copy link
Member

@KhafraDev KhafraDev left a 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?

@Uzlopak
Copy link
Contributor Author

Uzlopak commented Jun 4, 2025

The dispatch option is also not spec compliant

@mcollina
Copy link
Member

mcollina commented Jun 5, 2025

I don't think we should add these kind of features.

@Uzlopak
Copy link
Contributor Author

Uzlopak commented Jun 5, 2025

In smee-client we use the eventsource package. And with that we patch directly the reconnectionTime to 0 for immediate reconnect. I cant set the reconnectionTime with undici. Any suggestions?

@KhafraDev
Copy link
Member

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 undici/node object, something that cannot be mistaken as anything other than a deviation from the spec. Then we could add in a dispatcher/headers object later if needed.

This also would needs docs and tests.

new EventSource('https://my.event.source/', { node: { reconnectionTime: 0 } })

@KhafraDev
Copy link
Member

The dispatch option is also not spec compliant

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

@mcollina
Copy link
Member

We could add the namespaced one and deprecate the previous one in the next release (maybe major?).

@KhafraDev
Copy link
Member

KhafraDev commented Jun 15, 2025

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. 😂

@Uzlopak Uzlopak force-pushed the reconnection-time branch from 11d3380 to 0254706 Compare June 26, 2025 10:48
@Uzlopak
Copy link
Contributor Author

Uzlopak commented Jun 26, 2025

@mcollina
@KhafraDev

Is this to your liking? :)

@KhafraDev
Copy link
Member

Yes but there seem to be related test failures

@Uzlopak
Copy link
Contributor Author

Uzlopak commented Jun 30, 2025

@KhafraDev

Now runs through.

@Uzlopak Uzlopak dismissed a stale review July 9, 2025 10:22

Who is this actually?

@Uzlopak
Copy link
Contributor Author

Uzlopak commented Jul 17, 2025

@mcollina PTAL
@KhafraDev PTAL

mcollina added a commit that referenced this pull request Aug 4, 2025
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
@Uzlopak
Copy link
Contributor Author

Uzlopak commented Aug 11, 2025

@mcollina
@KhafraDev

PTAL. I think the test is now reasonable.

Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@KhafraDev KhafraDev merged commit b49a29a into main Aug 11, 2025
31 of 33 checks passed
@Uzlopak Uzlopak deleted the reconnection-time branch August 11, 2025 16:59
@github-actions github-actions bot mentioned this pull request Aug 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants