ricea / websocketstream-explainer Goto Github PK
View Code? Open in Web Editor NEWExplainer for the WebSocketStream JavaScript API
License: Apache License 2.0
Explainer for the WebSocketStream JavaScript API
License: Apache License 2.0
For example, with fetch
, one can specify headers. Sadly normal WS APi doesnt allow this. It would be great if one could set additional headers, or maybe at least cookie headers.
What's the purpose of this, given WebTransport? That spec covers this usecase, and provides all sorts of additional benefits.
Where is the spec discussion on this?
Indications from major browsers?
See WICG/direct-sockets#18 where the direct sockets API is trending in that direction. It might be best if everyone aligned.
close()
serves four purposes:
signal
passed in the constructor options can also do this.code
and reason
to a Close frame after the handshake has completed. However, the readable.cancel()
and writable.abort()
methods can also do this.readable
and writable
are locked. This might be useful if they have been transferred.The last two are the only things that can't be done another way. Are they sufficient to justify the existence of the method?
Please allow developers to pass custom headers into the constructor so they can, for example, provide an Authorization
header.
This would permit users some control over the trade-off between throughput and rapid backpressure detection.
quick question for some specifics: so the connection
resolves to {readable, writable}
ReadableStream
has a close(reason?)
and,
WritableStream
has an abort(reason?), and its Writer also has
closeand
abort`
do these effect the websocket? if so,
when close()
, with/without reason, what websocket code is sent?
when abort()
, with/without reason, what websocket code is sent?
when writer.abort()
, with/without reason, what websocket code is sent?
cheers
As the title says
How is close()
expected to behave if the user stopped reading the ReadableStream but there are a few messages in the queue up for grabs?
If you try to implement this spec with a simple ReadableStream you could have some unread messages that the stream didn't pull from the underlying because the user hasn't requested them via read()
, the stream won't actually get to reading the closing handshake - because the end user still hans't pulled the latest message available in the ReadableStream.
For example, the current Deno implementation (which is rightfully hidden behind an --unstable
flag) is broken because if you have more than 1 incoming message in the queue, and you're not intending to read it before or after calling close()
, the closing
promise will essentially remain unresolved. Here is an example of this behavior:
denoland/deno#15616
I think the spec needs to be clearer about the mechanics of how to do this, to prevent parties that implement this functionality from running into the same issue and getting too divergent on how they solve this problem.
For example:
WebSocketStreamOptions
?I think this part is trickier than it seems and it can benefit from a higher resolution description on the spec itself so that everyone implements it in a way that would behave the same. Right now it leaves too much room to the imagination.
Basic auth, cookies and client certificates cause a lot of problems for WebSockets. It would be nice to have an option to turn them off.
Unfortunately, I don't think we can turn them off by default because too many existing applications are depending them.
The WebSocket API is quite awkward in regard to ping/pong frames. It would be great if WSS could support them. Has there been any thoughts regarding that?
Assuming #12 is resolved in favour of keeping close()
, it would be good if it returned a promise.
Hello,
WebSocketStream is a great proposal to solve backpressure and cases where sockets are overflown with too many messages. The extension mechanism will also bring needed improvements to WebSockets.
However WebSockets suffer from a huge caveat: currently there is no way to ensure that a message has been sent through the websocket. None. Over a bad network (e.g. hotel wifis), a SINGLE message sent can fail silently with zero means to detect it.
That's a huge problem for reliability, and WebSocketStream are a great opportunity to solve this issue (as nothing else is evolving - See whatwg/html#4727).
This is vital for WebSockets and WebSocketStream: as more and more people find out that WebSockets are unreliable, all the work done around the WebSocketStream may turn useless.
Currently WebSocket.send()
stores the message in a buffer and returns immediately.
There is no guarantee that the message will ever be sent.
Even ws.bufferedAmount
is not reliable, as it may decrease when the connection is down (messages are passed to the underlying OS, and falsely considered to be sent).
Also, ws.send()
throws an error when the WebSocket is in readyState CONNECTING
, but fails silently when the WebSocket gets closed, which can easily occur with bad Wifi (high latency and dropped packets).
The only way to guarantee transmission is to implement an acknowledgement protocol on top of websockets, which is silly as it is already implemented at low level!
WebSocket.send()
should return a Promise (or have a callback mechanism) that resolves when the message has been successfully sent through the network, and rejects when the message won't be able to be sent (and provides the message that failed).
When searching the internet about this problem, the comments commonly found are "WebSockets are unreliable". It should not be so!
Thank you for helping the Internet become a better medium!
Just discovered this new WebSocketStream thing, but why wasn't it considered as a builtin module?
like the key/value storage?
https://developers.google.com/web/updates/2019/03/kv-storage
think that should be the new way of implementing new features...?
Maybe not too late to change it?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.