Intent to Ship: WebTransport

598 views
Skip to first unread message

Yutaka Hirano

unread,
Sep 27, 2021, 12:55:58 AMSep 27
to Victor Vasiliev, blink-dev

Contact emails

yhi...@chromium.org, vas...@chromium.org


Explainer

https://github.com/w3c/webtransport/blob/main/explainer.md


Specification

https://w3c.github.io/webtransport

https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/

https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/


Design docs

https://web.dev/webtransport/

https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit


Summary

WebTransport is an interface representing a set of reliable/unreliable streams to a server. The interface potentially supports multiple protocols, but based on discussions on the IETF webtrans working group, we are developing WebTransport over HTTP/3 which uses HTTP3 as the underlying protocol.


This time, we want to ship the core part. The following features are excluded:

  • Connection sharing

  • Stream Prioritization

  • Statistics

  • WebTransport over HTTP/2


Blink component

Blink>Network>WebTransport


TAG review

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


TAG review status

Pending


Risks


Interoperability and Compatibility  


This is a new API and doesn’t change any existing behaviors.


Gecko: Worth Prototyping. They are actively involved in the specification effort.


WebKit: No signal.


Web developers: Positive

Twitch

https://twitch.tv

 

Twitch is using WebTransport to serve live video to our users with lower latency and higher quality. We plan on rolling out our new playback experience once it's fully available given our positive results.

 

WebTransport offers all of the benefits of QUIC, but in a browser environment and without the constraints of HTTP semantics. Most notably we can push data over multiple streams, eliminating head-of-line blocking and enabling new functionality during congestion. This is not possible with existing browser standards such as WebSockets and WebRTC data channels.


Google Stadia

https://stadia.google.com/


“Google Stadia is using the WebTransport API in conjunction with the WebCodecs API for several use cases, both internally and with partners. The underlying WebTransport protocol, QUIC, has far greater throughput and resiliency characteristics than other mechanisms available, which enables use cases like webcams, and transmission of results of browser-based processing to applications and games in the cloud. The capability to transmit datagrams to cloud endpoints enables many new use cases for Stadia including communication with custom hardware endpoints. In the future we hope to explore using this API for other use cases.”


Ergonomics

The API is built around ReadableStream/WritableStream interfaces, which means that its core I/O principles would be familiar to the developers who had already used Streams via Fetch and other APIs.


The API does not use cookies, HTTP authentication or socket pooling.  This would help us avoid unexpected interactions with the other elements of the network stack.


Activation

Since UDP is often blocked on the network, the developers have to assume that the API often would not work even in the situations when it is implemented in the browser.


Security

See <https://wicg.github.io/web-transport/#privacy-security> for more info.

 

We allow web developers to use an alternative certification verification method than the usual HTTPS way. We allow a web developer to connect to a WebTransport over HTTP/3 server when its certificate’s fingerprint matches with the developer provided fingerprint. This is discussed at https://github.com/w3c/webtransport/issues/349 and we will update the spec shortly.


Debuggability

Printing an error message with the reason when the opening handshake fails.


We show outgoing WebTransport sessions in the “Network” section of DevTools, the same place where WebSocket connections are shown.  Unlike WebSockets, we do not intend to show the actual contents of the WebTransport sessions, thus avoiding the performance decrease that would cause.


Just like with regular HTTP/3-based QUIC traffic, detailed information about the connection can be obtained via chrome://net-export interface.


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

Yes


We are writing WPTs (/webtransport). We expect the task to be completed by the branch point. The WebTransport over HTTP/3 server for testing is running locally, but we need more time to run it on wpt.live or Chromium CI. 


Requires code in //chrome?

False


Tracking bug

https://crbug.com/10111392


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4854144902889472


Emily Stark

unread,
Sep 28, 2021, 6:08:24 PMSep 28
to Yutaka Hirano, Victor Vasiliev, blink-dev, David Benjamin
I want to note that there are some pretty big open questions in https://github.com/w3c/webtransport/issues/349. I think we might want to have more restrictions on the allowed types of certificates than the spec currently outlines, and introducing those restrictions after shipping the feature would carry compatibility risks.

--
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/CABihn6HZaCbG_q8wVv0ukaGRwir-%2BVr0yQTGy3nXH0Qwa1fe%3Dg%40mail.gmail.com.

Philip Jägenstedt

unread,
Sep 29, 2021, 5:29:50 AMSep 29
to Emily Stark, Yutaka Hirano, Victor Vasiliev, blink-dev, David Benjamin
Hi Yutaka,

This is a big new feature and a lot to go over. When looking at the spec+Blink IDL, I noticed the API didn't require secure contexts:

It looks like that's being fixed now, which is great! I'll reply again when I've spent some more time reading here.

Yutaka Hirano

unread,
Sep 29, 2021, 6:32:08 AMSep 29
to Philip Jägenstedt, Emily Stark, Victor Vasiliev, blink-dev, David Benjamin
Hi Philip, 

On Wed, Sep 29, 2021 at 6:29 PM Philip Jägenstedt <foo...@chromium.org> wrote:
Hi Yutaka,

This is a big new feature and a lot to go over. When looking at the spec+Blink IDL, I noticed the API didn't require secure contexts:

It looks like that's being fixed now, which is great! I'll reply again when I've spent some more time reading here.

Thank you for pointing it out, and sorry for not fixing this earlier. 
 

Philip Jägenstedt

unread,
Sep 29, 2021, 10:25:39 AMSep 29
to Yutaka Hirano, Emily Stark, Victor Vasiliev, blink-dev, David Benjamin
On Wed, Sep 29, 2021 at 12:32 PM Yutaka Hirano <yhi...@chromium.org> wrote:
Hi Philip, 

On Wed, Sep 29, 2021 at 6:29 PM Philip Jägenstedt <foo...@chromium.org> wrote:
Hi Yutaka,

This is a big new feature and a lot to go over. When looking at the spec+Blink IDL, I noticed the API didn't require secure contexts:

It looks like that's being fixed now, which is great! I'll reply again when I've spent some more time reading here.

Thank you for pointing it out, and sorry for not fixing this earlier.

No worries, it's hard to spot these issues because there's no tooling around it.

I have spotted another difference that I'm not sure if it's intentional or not. The spec has a getStats() method which isn't implemented and I can't find a bug for it. Is this intentionally left until later, or should it be in the initial feature set?

Best regards,
Philip

Yutaka Hirano

unread,
Sep 30, 2021, 3:34:42 AMSep 30
to Philip Jägenstedt, Emily Stark, Victor Vasiliev, blink-dev, David Benjamin
I think that's covered in the Summary of the intent:

> This time, we want to ship the core part. The following features are excluded:

  • Connection sharing

  • Stream Prioritization

  • Statistics

  • WebTransport over HTTP/2


So, that is intentional.

Philip Jägenstedt

unread,
Sep 30, 2021, 5:57:42 AMSep 30
to Yutaka Hirano, Emily Stark, Victor Vasiliev, blink-dev, David Benjamin
On Thu, Sep 30, 2021 at 9:34 AM Yutaka Hirano <yhi...@chromium.org> wrote:
I think that's covered in the Summary of the intent:

> This time, we want to ship the core part. The following features are excluded:

  • Connection sharing

  • Stream Prioritization

  • Statistics

  • WebTransport over HTTP/2


So, that is intentional.

Sorry I missed that. Do you think bugs for each of these would be useful, or do you not really need that bookkeeping?

How serious is the lack of HTTP/2 support for web developers? Concretely, is this a serious enough limitation that the initial implementation should be considered partial on MDN/BCD?

I guess that connection sharing and stream prioritization aren't observable to users of the API, and are simply performance improvements that will be made later, is that right?

Philip Jägenstedt

unread,
Sep 30, 2021, 6:31:39 AMSep 30
to Yutaka Hirano, Victor Vasiliev, blink-dev
Hi again,

I've made a full pass of the intent now. I have a lot of questions, but am pretty convinced we should ship this, it's just a matter of what things need to block that, and what things can be left until later.

Comments inline...

On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano <yhi...@chromium.org> wrote:
I skimmed https://github.com/w3c/webtransport/issues/ and see multiple issues filed by other browser vendors. Are any of the remaining issues ones that could change the API's shape or behavior? It would be good to resolve any such issues, since they won't be possible to address once the API is locked in by sites depending on it.

Design docs

https://web.dev/webtransport/

https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit


Summary

WebTransport is an interface representing a set of reliable/unreliable streams to a server. The interface potentially supports multiple protocols, but based on discussions on the IETF webtrans working group, we are developing WebTransport over HTTP/3 which uses HTTP3 as the underlying protocol.


This time, we want to ship the core part. The following features are excluded:

  • Connection sharing

  • Stream Prioritization

  • Statistics

  • WebTransport over HTTP/2


Blink component

Blink>Network>WebTransport


TAG review

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


TAG review status

Pending


Our launch process docs says "You should have TAG sign-off on your API design by now" but I consider this a bug in the process docs. The request was sent on Aug 19 and has no feedback yet, I don't think we should block this intent on TAG review. If it happens soon enough, it would of course still be important to take it into account and possibly make adjustments before the feature reaches stable.
 

Risks


Interoperability and Compatibility  


This is a new API and doesn’t change any existing behaviors.


Gecko: Worth Prototyping. They are actively involved in the specification effort.


WebKit: No signal.


How about the technologies that WebTransport depends on? Per https://caniuse.com/http3, it's shipped in Firefox and experimental in Safari. Are you aware of any likely problems getting HTTP/3 itself into all browsers? If HTTP/3 is on a good track, that reduces the risk here.
 

Web developers: Positive

Twitch

https://twitch.tv

 

Twitch is using WebTransport to serve live video to our users with lower latency and higher quality. We plan on rolling out our new playback experience once it's fully available given our positive results.

 

WebTransport offers all of the benefits of QUIC, but in a browser environment and without the constraints of HTTP semantics. Most notably we can push data over multiple streams, eliminating head-of-line blocking and enabling new functionality during congestion. This is not possible with existing browser standards such as WebSockets and WebRTC data channels.


Google Stadia

https://stadia.google.com/


“Google Stadia is using the WebTransport API in conjunction with the WebCodecs API for several use cases, both internally and with partners. The underlying WebTransport protocol, QUIC, has far greater throughput and resiliency characteristics than other mechanisms available, which enables use cases like webcams, and transmission of results of browser-based processing to applications and games in the cloud. The capability to transmit datagrams to cloud endpoints enables many new use cases for Stadia including communication with custom hardware endpoints. In the future we hope to explore using this API for other use cases.”


This is great feedback, thank you for collecting it! It looks like both Twitch and Stadia are looking at video, where I assume that avoiding head-of-line blocking makes it possible to scale down quality faster when network conditions go bad. Sounds like a win for end users, ultimately!
 

Ergonomics

The API is built around ReadableStream/WritableStream interfaces, which means that its core I/O principles would be familiar to the developers who had already used Streams via Fetch and other APIs.


The API does not use cookies, HTTP authentication or socket pooling.  This would help us avoid unexpected interactions with the other elements of the network stack.


Activation

Since UDP is often blocked on the network, the developers have to assume that the API often would not work even in the situations when it is implemented in the browser.


This is interesting. How do web developers detect and deal with this situation, and distinguish it from the network temporarily going down? I've skimmed https://web.dev/webtransport/ and it doesn't mention this kind of blocking, does this need to be highlighted in documentation and reference docs for WebTransport?

Speaking of reference docs... Getting a feature documented on MDN isn't part of the Blink launch process, but are you working with anyone to get it documented by the time the feature reaches Chrome stable?
 

Security

See <https://wicg.github.io/web-transport/#privacy-security> for more info.

 

We allow web developers to use an alternative certification verification method than the usual HTTPS way. We allow a web developer to connect to a WebTransport over HTTP/3 server when its certificate’s fingerprint matches with the developer provided fingerprint. This is discussed at https://github.com/w3c/webtransport/issues/349 and we will update the spec shortly.


Debuggability

Printing an error message with the reason when the opening handshake fails.


We show outgoing WebTransport sessions in the “Network” section of DevTools, the same place where WebSocket connections are shown.  Unlike WebSockets, we do not intend to show the actual contents of the WebTransport sessions, thus avoiding the performance decrease that would cause.


Just like with regular HTTP/3-based QUIC traffic, detailed information about the connection can be obtained via chrome://net-export interface.


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

Yes


We are writing WPTs (/webtransport). We expect the task to be completed by the branch point. The WebTransport over HTTP/3 server for testing is running locally, but we need more time to run it on wpt.live or Chromium CI.


Here I just want to say that the WPT work for this feature has been great to see, adding new infrastructure and solving many small problems to make it possible. Thank you, this is key to ensuring that other implementations behave the same down the line.

Requires code in //chrome?

False


Tracking bug

https://crbug.com/10111392


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4854144902889472


Mike West

unread,
Sep 30, 2021, 7:22:26 AMSep 30
to Philip Jägenstedt, Yutaka Hirano, Victor Vasiliev, blink-dev
Like Philip, I think this is a useful mechanism, and I'd like to see it ship. I'm also happy with the work that's gone into it through now, and thankful that folks have been proactive both in terms of testing and outreach to security and privacy folks.

Like Emily, I think questions like https://github.com/w3c/webtransport/issues/349 are critical to get right, and will be hard to change once we've shipped. I'd like to see that in particular resolved before moving forward. https://github.com/w3c/webtransport/issues/332 would also be lovely to resolve.

-mike


Martin Thomson

unread,
Oct 1, 2021, 10:56:41 AMOct 1
to Mike West, Philip Jägenstedt, Yutaka Hirano, Victor Vasiliev, blink-dev
Given where things stand with issue 349, perhaps you might consider excluding that from the implementation.  It's an extension that can be added later very easily.

Yutaka Hirano

unread,
Oct 1, 2021, 3:27:48 PMOct 1
to Philip Jägenstedt, Victor Vasiliev, blink-dev
Hi Philip,

Sorry for the belated reply. Comments inline:

On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt <foo...@chromium.org> wrote:
Hi again,

I've made a full pass of the intent now. I have a lot of questions, but am pretty convinced we should ship this, it's just a matter of what things need to block that, and what things can be left until later.

Comments inline...

On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano <yhi...@chromium.org> wrote:

I skimmed https://github.com/w3c/webtransport/issues/ and see multiple issues filed by other browser vendors. Are any of the remaining issues ones that could change the API's shape or behavior? It would be good to resolve any such issues, since they won't be possible to address once the API is locked in by sites depending on it.


I believe we've addressed issues that may require breaking changes. You can see open/closed issues for the initial launch (this intent).  I shared our plan at a WG meeting in May and we've been working to find and resolve such issues since then. 

 

Design docs

https://web.dev/webtransport/

https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit


Summary

WebTransport is an interface representing a set of reliable/unreliable streams to a server. The interface potentially supports multiple protocols, but based on discussions on the IETF webtrans working group, we are developing WebTransport over HTTP/3 which uses HTTP3 as the underlying protocol.


This time, we want to ship the core part. The following features are excluded:

  • Connection sharing

  • Stream Prioritization

  • Statistics

  • WebTransport over HTTP/2


Blink component

Blink>Network>WebTransport


TAG review

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


TAG review status

Pending


Our launch process docs says "You should have TAG sign-off on your API design by now" but I consider this a bug in the process docs. The request was sent on Aug 19 and has no feedback yet, I don't think we should block this intent on TAG review. If it happens soon enough, it would of course still be important to take it into account and possibly make adjustments before the feature reaches stable.
 
Ack.


 

Risks


Interoperability and Compatibility  


This is a new API and doesn’t change any existing behaviors.


Gecko: Worth Prototyping. They are actively involved in the specification effort.


WebKit: No signal.


How about the technologies that WebTransport depends on? Per https://caniuse.com/http3, it's shipped in Firefox and experimental in Safari. Are you aware of any likely problems getting HTTP/3 itself into all browsers? If HTTP/3 is on a good track, that reduces the risk here.
 
I'm not aware of any problems.

With an HTTP/3 implementation (and Streams API) any browsers can implement the API in a reasonable timeframe I believe.
 

Web developers: Positive

Twitch

https://twitch.tv

 

Twitch is using WebTransport to serve live video to our users with lower latency and higher quality. We plan on rolling out our new playback experience once it's fully available given our positive results.

 

WebTransport offers all of the benefits of QUIC, but in a browser environment and without the constraints of HTTP semantics. Most notably we can push data over multiple streams, eliminating head-of-line blocking and enabling new functionality during congestion. This is not possible with existing browser standards such as WebSockets and WebRTC data channels.


Google Stadia

https://stadia.google.com/


“Google Stadia is using the WebTransport API in conjunction with the WebCodecs API for several use cases, both internally and with partners. The underlying WebTransport protocol, QUIC, has far greater throughput and resiliency characteristics than other mechanisms available, which enables use cases like webcams, and transmission of results of browser-based processing to applications and games in the cloud. The capability to transmit datagrams to cloud endpoints enables many new use cases for Stadia including communication with custom hardware endpoints. In the future we hope to explore using this API for other use cases.”


This is great feedback, thank you for collecting it! It looks like both Twitch and Stadia are looking at video, where I assume that avoiding head-of-line blocking makes it possible to scale down quality faster when network conditions go bad. Sounds like a win for end users, ultimately!
 

Ergonomics

The API is built around ReadableStream/WritableStream interfaces, which means that its core I/O principles would be familiar to the developers who had already used Streams via Fetch and other APIs.


The API does not use cookies, HTTP authentication or socket pooling.  This would help us avoid unexpected interactions with the other elements of the network stack.


Activation

Since UDP is often blocked on the network, the developers have to assume that the API often would not work even in the situations when it is implemented in the browser.


This is interesting. How do web developers detect and deal with this situation, and distinguish it from the network temporarily going down? I've skimmed https://web.dev/webtransport/ and it doesn't mention this kind of blocking, does this need to be highlighted in documentation and reference docs for WebTransport?

For usual loading browsers detect the network conditions and choose the right version (HTTP/3, HTTP/2 and HTTP/1.1). We may be able to do similar things in the future (on the other hand, we may end up asking web developers to detect it). Some people are working on WebTransport over HTTP/2

 

Speaking of reference docs... Getting a feature documented on MDN isn't part of the Blink launch process, but are you working with anyone to get it documented by the time the feature reaches Chrome stable?
 
I haven't talked with anyone. Do you have a good idea?
 

Security

See <https://wicg.github.io/web-transport/#privacy-security> for more info.

 

We allow web developers to use an alternative certification verification method than the usual HTTPS way. We allow a web developer to connect to a WebTransport over HTTP/3 server when its certificate’s fingerprint matches with the developer provided fingerprint. This is discussed at https://github.com/w3c/webtransport/issues/349 and we will update the spec shortly.


Debuggability

Printing an error message with the reason when the opening handshake fails.


We show outgoing WebTransport sessions in the “Network” section of DevTools, the same place where WebSocket connections are shown.  Unlike WebSockets, we do not intend to show the actual contents of the WebTransport sessions, thus avoiding the performance decrease that would cause.


Just like with regular HTTP/3-based QUIC traffic, detailed information about the connection can be obtained via chrome://net-export interface.


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

Yes


We are writing WPTs (/webtransport). We expect the task to be completed by the branch point. The WebTransport over HTTP/3 server for testing is running locally, but we need more time to run it on wpt.live or Chromium CI.


Here I just want to say that the WPT work for this feature has been great to see, adding new infrastructure and solving many small problems to make it possible. Thank you, this is key to ensuring that other implementations behave the same down the line.

Thank you very much for your support!

Victor Vasiliev

unread,
Oct 2, 2021, 8:32:53 PMOct 2
to Philip Jägenstedt, Yutaka Hirano, blink-dev
On Thu, Sep 30, 2021 at 6:31 AM Philip Jägenstedt <foo...@chromium.org> wrote:
Our launch process docs says "You should have TAG sign-off on your API design by now" but I consider this a bug in the process docs. The request was sent on Aug 19 and has no feedback yet, I don't think we should block this intent on TAG review. If it happens soon enough, it would of course still be important to take it into account and possibly make adjustments before the feature reaches stable.

Note that this has already received an early design review from TAG at <https://github.com/w3ctag/design-reviews/issues/389>, though the draft did change quite a bit since that happened.

Yang Guo

unread,
Oct 4, 2021, 2:49:57 AMOct 4
to blink-dev, Victor Vasiliev, Yutaka Hirano, blink-dev, Philip Jägenstedt
Thank you for thinking about debuggability! I understand the rationale behind not providing more details. Would it make sense though to link to chrome://net-export from DevTools' Network Panel? 

Yutaka Hirano

unread,
Oct 4, 2021, 7:38:38 AMOct 4
to Yang Guo, blink-dev, Victor Vasiliev, Philip Jägenstedt
On Mon, Oct 4, 2021 at 3:49 PM Yang Guo <yan...@google.com> wrote:
Thank you for thinking about debuggability! I understand the rationale behind not providing more details. Would it make sense though to link to chrome://net-export from DevTools' Network Panel? 

Actually after implementing the minimal support we asked if there were more requests on this front. There were no requests at that time, and I thought web developers might want more debugging features after we ship the feature. We're open to add more debugging features if there is a strong demand.

Would it make sense though to link to chrome://net-export from DevTools' Network Panel? 
Interesting. How can we do that?

Yang Guo

unread,
Oct 4, 2021, 8:23:07 AMOct 4
to Yutaka Hirano, blink-dev, Victor Vasiliev, Philip Jägenstedt
On Mon, Oct 4, 2021 at 1:38 PM Yutaka Hirano <yhi...@chromium.org> wrote:

On Mon, Oct 4, 2021 at 3:49 PM Yang Guo <yan...@google.com> wrote:
Thank you for thinking about debuggability! I understand the rationale behind not providing more details. Would it make sense though to link to chrome://net-export from DevTools' Network Panel? 

Actually after implementing the minimal support we asked if there were more requests on this front. There were no requests at that time, and I thought web developers might want more debugging features after we ship the feature. We're open to add more debugging features if there is a strong demand.

SGTM
 

Would it make sense though to link to chrome://net-export from DevTools' Network Panel? 
Interesting. How can we do that?


I was thinking of what we are doing for service worker registrations, which looks like this:

Screenshot 2021-10-04 at 14.20.46.png
"See all registrations" links to chrome://serviceworker-internals/?devtools. I can imagine linking to chrome://net-export in the details view for Web Transport entries in the Network panel's log, if that makes sense.

Cheers,

Yang

Philip Jägenstedt

unread,
Oct 4, 2021, 9:04:39 AMOct 4
to Yutaka Hirano, Joe Medley, Victor Vasiliev, blink-dev
On Fri, Oct 1, 2021 at 9:27 PM Yutaka Hirano <yhi...@chromium.org> wrote:
Hi Philip,

Sorry for the belated reply. Comments inline:

On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt <foo...@chromium.org> wrote:
Hi again,

I've made a full pass of the intent now. I have a lot of questions, but am pretty convinced we should ship this, it's just a matter of what things need to block that, and what things can be left until later.

Comments inline...

On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano <yhi...@chromium.org> wrote:

I skimmed https://github.com/w3c/webtransport/issues/ and see multiple issues filed by other browser vendors. Are any of the remaining issues ones that could change the API's shape or behavior? It would be good to resolve any such issues, since they won't be possible to address once the API is locked in by sites depending on it.


I believe we've addressed issues that may require breaking changes. You can see open/closed issues for the initial launch (this intent).  I shared our plan at a WG meeting in May and we've been working to find and resolve such issues since then.

I see, creating a milestone for this is really handy! Are the remaining issue in https://github.com/w3c/webtransport/milestone/1 not blocking then, even issue #349?

Activation

Since UDP is often blocked on the network, the developers have to assume that the API often would not work even in the situations when it is implemented in the browser.


This is interesting. How do web developers detect and deal with this situation, and distinguish it from the network temporarily going down? I've skimmed https://web.dev/webtransport/ and it doesn't mention this kind of blocking, does this need to be highlighted in documentation and reference docs for WebTransport?

For usual loading browsers detect the network conditions and choose the right version (HTTP/3, HTTP/2 and HTTP/1.1). We may be able to do similar things in the future (on the other hand, we may end up asking web developers to detect it). Some people are working on WebTransport over HTTP/2

With the implementation as it is now, what will the behavior be on a network where UDP is blocked? Presumably the initial connection that serves HTML and scripts has then been negotiated to HTTP/2 or HTTP/1.1, but is there any indication in the API that WebTransport is going to fail ahead of time, or error that can be distinguished from an intermittent network error? I'm thinking of the code to fall back to WebSockets that might be necessary here, how one would determine that the fallback is needed.

Speaking of reference docs... Getting a feature documented on MDN isn't part of the Blink launch process, but are you working with anyone to get it documented by the time the feature reaches Chrome stable?
 
I haven't talked with anyone. Do you have a good idea?

As I said this isn't a required part of the launch process, but +Joe Medley knows the documentation process very well. Joe, where would you suggest to start in order to ensure a feature becomes documented on MDN around the time it reaches stable?

Yutaka Hirano

unread,
Oct 5, 2021, 8:48:18 AMOct 5
to Yang Guo, blink-dev, Victor Vasiliev, Philip Jägenstedt
On Mon, Oct 4, 2021 at 9:22 PM Yang Guo <yan...@google.com> wrote:


On Mon, Oct 4, 2021 at 1:38 PM Yutaka Hirano <yhi...@chromium.org> wrote:

On Mon, Oct 4, 2021 at 3:49 PM Yang Guo <yan...@google.com> wrote:
Thank you for thinking about debuggability! I understand the rationale behind not providing more details. Would it make sense though to link to chrome://net-export from DevTools' Network Panel? 

Actually after implementing the minimal support we asked if there were more requests on this front. There were no requests at that time, and I thought web developers might want more debugging features after we ship the feature. We're open to add more debugging features if there is a strong demand.

SGTM
 

Would it make sense though to link to chrome://net-export from DevTools' Network Panel? 
Interesting. How can we do that?


I was thinking of what we are doing for service worker registrations, which looks like this:

Screenshot 2021-10-04 at 14.20.46.png
"See all registrations" links to chrome://serviceworker-internals/?devtools. I can imagine linking to chrome://net-export in the details view for Web Transport entries in the Network panel's log, if that makes sense.

Thank you. chrome://net-export may not be as useful as chrome://serviceworker-internals in that context, because chrome://serviceworker-internals show information whereas chrome://net-export is a tool to record network activities.

Yutaka Hirano

unread,
Oct 5, 2021, 9:20:47 AMOct 5
to Philip Jägenstedt, Joe Medley, Victor Vasiliev, blink-dev
On Mon, Oct 4, 2021 at 10:04 PM Philip Jägenstedt <foo...@chromium.org> wrote:
On Fri, Oct 1, 2021 at 9:27 PM Yutaka Hirano <yhi...@chromium.org> wrote:
Hi Philip,

Sorry for the belated reply. Comments inline:

On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt <foo...@chromium.org> wrote:
Hi again,

I've made a full pass of the intent now. I have a lot of questions, but am pretty convinced we should ship this, it's just a matter of what things need to block that, and what things can be left until later.

Comments inline...

On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano <yhi...@chromium.org> wrote:

I skimmed https://github.com/w3c/webtransport/issues/ and see multiple issues filed by other browser vendors. Are any of the remaining issues ones that could change the API's shape or behavior? It would be good to resolve any such issues, since they won't be possible to address once the API is locked in by sites depending on it.


I believe we've addressed issues that may require breaking changes. You can see open/closed issues for the initial launch (this intent).  I shared our plan at a WG meeting in May and we've been working to find and resolve such issues since then.

I see, creating a milestone for this is really handy! Are the remaining issue in https://github.com/w3c/webtransport/milestone/1 not blocking then, even issue #349?

Except for issue #349 we have consensus on discussions. As Victor commented in this thread, we can ship WebTransport except for customeCertificationHashes if needed. 
 

Activation

Since UDP is often blocked on the network, the developers have to assume that the API often would not work even in the situations when it is implemented in the browser.


This is interesting. How do web developers detect and deal with this situation, and distinguish it from the network temporarily going down? I've skimmed https://web.dev/webtransport/ and it doesn't mention this kind of blocking, does this need to be highlighted in documentation and reference docs for WebTransport?

For usual loading browsers detect the network conditions and choose the right version (HTTP/3, HTTP/2 and HTTP/1.1). We may be able to do similar things in the future (on the other hand, we may end up asking web developers to detect it). Some people are working on WebTransport over HTTP/2

With the implementation as it is now, what will the behavior be on a network where UDP is blocked? Presumably the initial connection that serves HTML and scripts has then been negotiated to HTTP/2 or HTTP/1.1, but is there any indication in the API that WebTransport is going to fail ahead of time, or error that can be distinguished from an intermittent network error? I'm thinking of the code to fall back to WebSockets that might be necessary here, how one would determine that the fallback is needed.

To prevent malicious web developers from sniffing the network conditions, we don't expose detailed network error information to web developers when session establishment fails.
So currently web developers can 1) retry establishing a session with a fallback protocol (e.g., WebSocket), or 2) race two (or more?) session establishment operations.
Of course, web apps can use other information such as the results of past attempts, geolocation information, and so on.
 
The current way is very primitive, and we may be able to provide more sophisticated means in the future.

Yang Guo

unread,
Oct 5, 2021, 1:38:27 PMOct 5
to Yutaka Hirano, blink-dev, Victor Vasiliev, Philip Jägenstedt
Got it. In that case I agree that there is not much actionable at this point :)

Yang

Yutaka Hirano

unread,
Oct 6, 2021, 9:00:13 AMOct 6
to Philip Jägenstedt, Joe Medley, Victor Vasiliev, blink-dev
Hi, are there any unanswered questions? Or, do you have more comments or questions?

We are open to ship this feature without the custom certificate part, which means shipping this feature and continuing discussing issue #349.

Thanks,

Philip Jägenstedt

unread,
Oct 7, 2021, 3:45:35 AMOct 7
to Yutaka Hirano, Joe Medley, Victor Vasiliev, blink-dev
On Tue, Oct 5, 2021 at 3:20 PM Yutaka Hirano <yhi...@chromium.org> wrote:


On Mon, Oct 4, 2021 at 10:04 PM Philip Jägenstedt <foo...@chromium.org> wrote:
On Fri, Oct 1, 2021 at 9:27 PM Yutaka Hirano <yhi...@chromium.org> wrote:
Hi Philip,

Sorry for the belated reply. Comments inline:

On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt <foo...@chromium.org> wrote:
Hi again,

I've made a full pass of the intent now. I have a lot of questions, but am pretty convinced we should ship this, it's just a matter of what things need to block that, and what things can be left until later.

Comments inline...

On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano <yhi...@chromium.org> wrote:

I skimmed https://github.com/w3c/webtransport/issues/ and see multiple issues filed by other browser vendors. Are any of the remaining issues ones that could change the API's shape or behavior? It would be good to resolve any such issues, since they won't be possible to address once the API is locked in by sites depending on it.


I believe we've addressed issues that may require breaking changes. You can see open/closed issues for the initial launch (this intent).  I shared our plan at a WG meeting in May and we've been working to find and resolve such issues since then.

I see, creating a milestone for this is really handy! Are the remaining issue in https://github.com/w3c/webtransport/milestone/1 not blocking then, even issue #349?

Except for issue #349 we have consensus on discussions. As Victor commented in this thread, we can ship WebTransport except for customeCertificationHashes if needed. 

If custom certificates is a nice-to-have then shipping without it seems fine to me. That would mean removing serverCertificateHashes from the dictionary, right? I ask because the spec also says something about NotSupportedError when the protocol doesn't support it, but it seems better to behave as if the feature doesn't exist at all.

Looking through some other issues:
Having consensus on the issues is great, but some things are still much harder to fix after shipping, or harder to get prioritized after shipping, so that's why I'm asking.

Activation

Since UDP is often blocked on the network, the developers have to assume that the API often would not work even in the situations when it is implemented in the browser.


This is interesting. How do web developers detect and deal with this situation, and distinguish it from the network temporarily going down? I've skimmed https://web.dev/webtransport/ and it doesn't mention this kind of blocking, does this need to be highlighted in documentation and reference docs for WebTransport?

For usual loading browsers detect the network conditions and choose the right version (HTTP/3, HTTP/2 and HTTP/1.1). We may be able to do similar things in the future (on the other hand, we may end up asking web developers to detect it). Some people are working on WebTransport over HTTP/2

With the implementation as it is now, what will the behavior be on a network where UDP is blocked? Presumably the initial connection that serves HTML and scripts has then been negotiated to HTTP/2 or HTTP/1.1, but is there any indication in the API that WebTransport is going to fail ahead of time, or error that can be distinguished from an intermittent network error? I'm thinking of the code to fall back to WebSockets that might be necessary here, how one would determine that the fallback is needed.

To prevent malicious web developers from sniffing the network conditions, we don't expose detailed network error information to web developers when session establishment fails.
So currently web developers can 1) retry establishing a session with a fallback protocol (e.g., WebSocket), or 2) race two (or more?) session establishment operations.
Of course, web apps can use other information such as the results of past attempts, geolocation information, and so on.
 
The current way is very primitive, and we may be able to provide more sophisticated means in the future.

I see, that's unfortunate but makes sense.

Yutaka Hirano

unread,
Oct 7, 2021, 4:04:53 AMOct 7
to Philip Jägenstedt, Joe Medley, Victor Vasiliev, blink-dev
Thank you!

On Thu, Oct 7, 2021 at 4:45 PM Philip Jägenstedt <foo...@chromium.org> wrote:
On Tue, Oct 5, 2021 at 3:20 PM Yutaka Hirano <yhi...@chromium.org> wrote:


On Mon, Oct 4, 2021 at 10:04 PM Philip Jägenstedt <foo...@chromium.org> wrote:
On Fri, Oct 1, 2021 at 9:27 PM Yutaka Hirano <yhi...@chromium.org> wrote:
Hi Philip,

Sorry for the belated reply. Comments inline:

On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt <foo...@chromium.org> wrote:
Hi again,

I've made a full pass of the intent now. I have a lot of questions, but am pretty convinced we should ship this, it's just a matter of what things need to block that, and what things can be left until later.

Comments inline...

On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano <yhi...@chromium.org> wrote:

I skimmed https://github.com/w3c/webtransport/issues/ and see multiple issues filed by other browser vendors. Are any of the remaining issues ones that could change the API's shape or behavior? It would be good to resolve any such issues, since they won't be possible to address once the API is locked in by sites depending on it.


I believe we've addressed issues that may require breaking changes. You can see open/closed issues for the initial launch (this intent).  I shared our plan at a WG meeting in May and we've been working to find and resolve such issues since then.

I see, creating a milestone for this is really handy! Are the remaining issue in https://github.com/w3c/webtransport/milestone/1 not blocking then, even issue #349?

Except for issue #349 we have consensus on discussions. As Victor commented in this thread, we can ship WebTransport except for customeCertificationHashes if needed. 

If custom certificates is a nice-to-have then shipping without it seems fine to me. That would mean removing serverCertificateHashes from the dictionary, right? I ask because the spec also says something about NotSupportedError when the protocol doesn't support it, but it seems better to behave as if the feature doesn't exist at all.


The property is protected by WebTransportCustomCertificates, so when we enable only WebTransport, the property will be invisible.


 
Looking through some other issues:
  • Can https://github.com/w3c/webtransport/issues/59 be resolved for the WebPKI case? If CSP currently has no effect, then adding it on later could be hard because some sites could already be using CSP that would block it, and those sites would be broken by adding CSP support later.

Yes I think so. We check the "connect-src" directive. It is tested as csp-fail.https.window.js and csp-pass.window.js.

I think this is to describe our current protection and won't affect implementation.
 
This is about how to describe algorithms in the spec in terms of threading, and this won't impact implementation.

Philip Jägenstedt

unread,
Oct 7, 2021, 4:38:37 AMOct 7
to Yutaka Hirano, Joe Medley, Victor Vasiliev, blink-dev
Great, thanks for confirming!
 
Looking through some other issues:
  • Can https://github.com/w3c/webtransport/issues/59 be resolved for the WebPKI case? If CSP currently has no effect, then adding it on later could be hard because some sites could already be using CSP that would block it, and those sites would be broken by adding CSP support later.

Yes I think so. We check the "connect-src" directive. It is tested as csp-fail.https.window.js and csp-pass.window.js.

That's good, the risk I was worried about doesn't exist then. Would you consider that this behavior is required by some spec, even though it's not mentioned in https://w3c.github.io/webtransport/? If not, then do you think it's reasonable to prioritize the spec work for this before this reaches stable? 

I think this is to describe our current protection and won't affect implementation.
 
This is about how to describe algorithms in the spec in terms of threading, and this won't impact implementation.

 Again, thanks for confirming!

Yutaka Hirano

unread,
Oct 7, 2021, 4:51:59 AMOct 7
to Philip Jägenstedt, Joe Medley, Victor Vasiliev, blink-dev
This behavior should be specified, and yes I think that effort should be prioritized. I'm happy to work on that.

Yutaka Hirano

unread,
Oct 7, 2021, 10:53:21 AMOct 7
to Philip Jägenstedt, Joe Medley, Victor Vasiliev, blink-dev

Mike West

unread,
Oct 7, 2021, 3:19:51 PMOct 7
to Yutaka Hirano, Philip Jägenstedt, Joe Medley, Victor Vasiliev, blink-dev
LGTM1, to ship this without the certificate fingerprint portion of 349 discussed above. There's still some conversation to be had there, and I think it's worth finishing the discussion before shipping it since it's quite clearly separable. I'd suggest shipping that as a separate intent if that's the way the conversation goes.

I appreciate Philip's comments as well, and I'm happy to see that y'all have already put up a PR to add CSP support. I think we should probably alter the CSP spec to make your PR more clear, but that's not something I think we ought to block on.

I'll also note that the TAG just put this on their agenda for this coming week. If concerns are raised there, I would appreciate us addressing them thoroughly before shipping.

-mike


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

Yoav Weiss

unread,
Oct 8, 2021, 1:18:02 AMOct 8
to Mike West, Yutaka Hirano, Philip Jägenstedt, Joe Medley, Victor Vasiliev, blink-dev
LGTM2 to ship without certificate fingerprints. It'd be great to ensure public documentation for this includes the fallback mechanism we want developers to implement. (both in the web.dev article and future MDN documentation).

Rick Byers

unread,
Oct 8, 2021, 12:08:01 PMOct 8
to Yoav Weiss, Mike West, Yutaka Hirano, Philip Jägenstedt, Joe Medley, Victor Vasiliev, blink-dev
LGTM3 

It's exciting to see this shipping! Lack of datagram networking has been a hole in the platform for a long time.



Yutaka Hirano

unread,
Oct 12, 2021, 2:53:19 AMOct 12
to Rick Byers, Yoav Weiss, Mike West, Philip Jägenstedt, Joe Medley, Victor Vasiliev, blink-dev
Thank you! We'll land the shipping CL after addressing TAG review comments.

Yutaka Hirano

unread,
Oct 18, 2021, 3:35:53 AMOct 18
to Rick Byers, Yoav Weiss, Mike West, Philip Jägenstedt, Joe Medley, Victor Vasiliev, blink-dev
> I'll also note that the TAG just put this on their agenda for this coming week. If concerns are raised there, I would appreciate us addressing them thoroughly before shipping.

The week of 2021-10-11 ended but we haven't heard anything from them. I'm planning to land the change.
Reply all
Reply to author
Forward
0 new messages