Intent to Ship: WebSocketStream

1,112 views
Skip to first unread message

Adam Rice

unread,
Feb 6, 2024, 4:43:46 PMFeb 6
to blink-dev

Contact emails

ri...@chromium.org

Explainer

https://github.com/ricea/websocketstream-explainer/blob/master/README.md
https://docs.google.com/document/d/1XuxEshh5VYBYm1qRVKordTamCOsR-uGQBCYFcHXP4L0/edit

Specification

https://github.com/whatwg/websockets/pull/48

Design docs


https://web.dev/websocketstream/

Summary

The WebSocket API provides a JavaScript interface to the RFC6455 WebSocket protocol. While it has served well, it is awkward from an ergonomics perspective and is missing the important feature of backpressure. The intent of the WebSocketStream API is to resolve these deficiencies by integrating WHATWG Streams with the WebSocket API.



Blink component

Blink>Network>WebSockets

Search tags

WebSocketStreamsReadableStreamWritableStream

TAG review

https://github.com/w3ctag/design-reviews/issues/394

TAG review status

Pending

Chromium Trial Name

WebSocketStream

Link to origin trial feedback summary

https://github.com/ricea/websocketstream-explainer/issues

Origin Trial documentation link

https://github.com/ricea/websocketstream-explainer/blob/master/README.md

Risks



Interoperability and Compatibility

The main risk is that it fails to become an interoperable part of the web platform if other browsers do not implement it.



Gecko: No signal (https://github.com/mozilla/standards-positions/issues/970)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/315)

Web developers: No signals

Other signals: The Deno runtime has implemented the API: https://github.com/denoland/deno/issues/8831

Ergonomics

A major focus of the new API is improving ergonomics over the existing WebSocket API.



Activation

Everything except for correct backpressure behaviour can be polyfilled. Developers who are sensitive to backpressure may prefer to feature-detect and fall back to application-level backpressure if the feature is not available.



Security

Security posture is the same as the existing WebSocket API. The WebSocket mojo IPC layer was designed to support backpressure and didn't need changes to support the new API.



WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No specific risk.



Debuggability

The necessary probes are included in the code so that existing WebSocket debugging facilities work as-is.



Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

The feature is easy to support everywhere existing Blink WebSocket support exists. Blink WebSockets are supported on every Blink platform.



Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/websockets/stream/tentative



Flag name on chrome://flags

about://flags/#enable-experimental-web-platform-features

Finch feature name

WebSocketStream

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=983030

Measurement

Use counter: https://chromestatus.com/metrics/feature/timeline/popularity/3018

Availability expectation

The feature is relatively straightforward to implement, so I would expect it to be available in other browsers within 12 months.

Adoption expectation

We have a partner who is ready to adopt this as soon as it's available as the backpressure feature is critical for them.

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

No.

Sample links


https://github.com/ricea/websocketstream-explainer/blob/master/README.md

Estimated milestones

OriginTrial desktop last80
OriginTrial desktop first78
DevTrial on desktop78
DevTrial on Android78


Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

In future it is likely that an option to use byte streams will be added, to allow efficient use of BYOB readers. The second parameter to the constructor is an option bag, permitting easy extensions. https://github.com/ricea/websocketstream-explainer/issues/15 is about an interesting case where a clean close is not possible when there is too much unread data. A fix for this will not break existing users. Support for ping/pong frames, and sending custom request headers with the handshake are popular requests for both the WebSocket and WebSocketStream APIs. These can be implemented without incompatible changes to the API (though on the server side they will cause much trouble). There are other open issues at https://github.com/ricea/websocketstream-explainer/issues but nothing that needs to be addressed urgently.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5189728691290112

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/X7rWpAkMCyg/m/j6K7mEEwAgAJ Intent to Experiment: https://groups.google.com/a/chromium.org/d/msg/blink-dev/SUaSJzLQ1Yc/jmk7A-maAAAJ


This intent message was generated by Chrome Platform Status.

Alex Russell

unread,
Feb 7, 2024, 2:23:08 PMFeb 7
to blink-dev, Adam Rice
Hey Adam,

Glad to see this moving forward! Has there been a summary somewhere of the OT feedback? Also, we noted that the other reviews were marked as unstarted in chromestatus; we will likely hold off voting until those are in flight.

Thanks!

Adam Rice

unread,
Feb 8, 2024, 1:30:39 AMFeb 8
to Alex Russell, blink-dev
Unfortunately, no partners were ready when we did the OT, so there was no feedback at all. However, we have subsequently received private feedback that the API works well.

Mike Taylor

unread,
Feb 14, 2024, 11:39:31 AMFeb 14
to Adam Rice, blink-dev, Alex Russell

Hi Adam,

Would you mind requesting approvals in the chromestatus entry for the various review gates?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC_ixdwX4dnvpwsOJ7nm%2BW6UYs%2BNwQ_gHZJD7yvzTcawD2Rw8w%40mail.gmail.com.

Adam Rice

unread,
Feb 15, 2024, 7:17:18 AMFeb 15
to Mike Taylor, blink-dev, Alex Russell
Thanks Mike,

I have requested the approvals. Sorry for the delay, I didn't understand the interface.

Adam

Mike Taylor

unread,
Feb 15, 2024, 10:55:03 AMFeb 15
to Adam Rice, blink-dev, Alex Russell

Thank you - LGTM1

Chris Harrelson

unread,
Feb 15, 2024, 1:50:26 PMFeb 15
to Mike Taylor, Adam Rice, blink-dev, Alex Russell
Hi,

Any reason the PR for the spec hasn't landed yet?

Adam Rice

unread,
Feb 16, 2024, 3:10:50 AMFeb 16
to Chris Harrelson, Mike Taylor, blink-dev, Alex Russell
Any reason the PR for the spec hasn't landed yet?

We don't have interest from a second implementer yet. As far as I know, Deno doesn't count for this purpose.

Alex Russell

unread,
Feb 21, 2024, 11:53:12 AMFeb 21
to blink-dev, Adam Rice, Mike Taylor, blink-dev, Alex Russell, Chris Harrelson
Hey Adam,

Sorry for the slow follow up. Were there folks beyond the Deno ecosystem that expressed interest and/or satisfaction with the design? We're need to make a case in API OWNERS that there's enough developer interest to surmount the lack of other vendor interest. Are you able to share more?

Thanks,

Alex

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Adam Rice

unread,
Mar 4, 2024, 6:46:59 PMMar 4
to Alex Russell, blink-dev, Mike Taylor, Chris Harrelson
Thanks Alex,

We have a partner who need backpressure to avoid jank in their app. I've been waiting for them to comment, but it's taking a while.

Adam

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Domenic Denicola

unread,
Mar 5, 2024, 4:10:42 AMMar 5
to blink-dev, Adam Rice, blink-dev, Mike Taylor, Chris Harrelson, Alex Russell
LGTM2.

I appreciate Adam's careful attention to all portions of the process here, and also Alex's probing as to whether we're meeting the developer interest portion. Although this would be more of a slam-dunk if we were able to get that partner to comment publicly on their experience, I'm willing to take Adam's word on it about the private feedback.

Combined with the general positive sentiment, e.g. from Deno (which is a server-side runtime, but I think we have a good amount of experience showing that people like writing the same code across server and browser), and in response to the 2020 article, and the repeated "when is this coming" comments in the tracking bug... I think we have enough evidence that this will move the web forward in a positive way.

With my API owner hat off, I'm also just happy about this API existing, as I think it's generally good for the platform when we go back and take older, but still popular technologies, and retrofit them with modern capabilities and APIs like backpressure-supporting streams. It makes the web feel more cohesive and well-designed.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Thomas Steiner

unread,
Mar 5, 2024, 4:16:39 AMMar 5
to Domenic Denicola, blink-dev, Adam Rice, Mike Taylor, Chris Harrelson, Alex Russell
As an additional developer signal showing that developers want this, there's a polyfill: https://github.com/CarterLi/websocketstream-polyfill

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/51712f36-d16a-4b6e-baf9-da35b4785f04n%40chromium.org.


--
Thomas Steiner, PhD—Developer Relations Engineer (blog.tomayac.comtoot.cafe/@tomayac)

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891

----- BEGIN PGP SIGNATURE -----
Version: GnuPG v2.4.3 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck
0fjumBl3DCharaCTersAttH3b0ttom.xKcd.cOm/1181.
----- END PGP SIGNATURE -----

Yoav Weiss (@Shopify)

unread,
Mar 6, 2024, 12:11:59 AMMar 6
to Thomas Steiner, Domenic Denicola, blink-dev, Adam Rice, Mike Taylor, Chris Harrelson, Alex Russell
Reply all
Reply to author
Forward
0 new messages