Skip to content
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

Create a fetch-based WebSocket wrapper #62

Closed
dead-claudia opened this issue Oct 2, 2024 · 3 comments
Closed

Create a fetch-based WebSocket wrapper #62

dead-claudia opened this issue Oct 2, 2024 · 3 comments
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest

Comments

@dead-claudia
Copy link

What problem are you trying to solve?

Issues like #16 and #18 eventually extend to requiring arbitrary HTTP manipulation, and implementors (notably Chromium) have found it very difficult to extend it with arbitrary header support, having fused it with images.

There's also no way to inspect the response data or even view the HTTP response code of a rejected WebSocket connection attempt.

What solutions exist today?

Currently, none. You can get halfway there with fetch({duplex: "half"}), but the necessary WebSocket setup headers are all forbidden by fetch.

How would you solve it?

Something like this:

response = await fetch(url, {mode: "websocket"}): Set up a WebSocket request.

  • Pass for the body an object stream of strings and array buffers to send.
  • response.body contains a similar object stream of results, if response.status === 101. This stream has an overridden close method that lets callers close.
  • response also contains any headers sent back from the server.
  • All the other fetch options work as usual.

Anything else?

There already is some userland precedent for such an API: https://www.npmjs.com/package/@microsoft/fetch-event-source

@dead-claudia dead-claudia added addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest labels Oct 2, 2024
@ricea
Copy link
Collaborator

ricea commented Oct 2, 2024

The WebSocket API intentionally doesn't expose the reasons for connection failure to JavaScript, to avoid cross-origin information leakage.

We could in principle expose the information if the connection was same-origin, or if the server had permitted it via some CORS-like mechanism.

However, I don't know what the use case would be.

@annevk
Copy link
Member

annevk commented Oct 2, 2024

First we need agreement as to whether we want to solve a particular problem. Then we can figure out the syntax needed for it. #16 and #18 are well-suited for exploring the former. If you want some other piece of information, best to file a dedicated issue for it with use cases and such. See also https://whatwg.org/faq#adding-new-features.

@annevk annevk closed this as not planned Won't fix, can't repro, duplicate, stale Oct 2, 2024
@dead-claudia
Copy link
Author

@annevk I'll continue with this in #16 and link to it in #18, then. Sorry for the noise.

@ricea The fetch integration was intended to imply CORS integration and such, basically everything fetch already does. Sorry for not clarifying it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest
Development

No branches or pull requests

3 participants