ricea / websocketstream-explainer Goto Github PK

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:

1. Abort the handshake. However, the signal passed in the constructor options can also do this.
2. Pass code and reason to a Close frame after the handshake has completed. However, the readable.cancel() and writable.abort() methods can also do this.
3. Close even if both readable and writable are locked. This might be useful if they have been transferred.
4. End the connection unconditionally regardless of the current state.

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 closeandabort`

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:

1. You could say it's the responsibility of the user to explicitly fast forward the reader() until you get the close frame message.
2. You could fill up the controller queue "for the user" even if he won't read it (I guess it's kind of my preferred way?)
3. How do you react if the server you're interfacing with is not acting to-spec? The RFC spec says "wait a reasonable amount of time and then disconnect (the RFC 6455 section on close frames)". What is this reasonable amount of time? Should it be configurable in 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.

@ricea @tomayac

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.

Technical details:

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?