Skip to content

Experimental WebTransport support for phoenix#6604

Draft
lukaszsamson wants to merge 1 commit intophoenixframework:mainfrom
lukaszsamson:webtransport-implementation
Draft

Experimental WebTransport support for phoenix#6604
lukaszsamson wants to merge 1 commit intophoenixframework:mainfrom
lukaszsamson:webtransport-implementation

Conversation

@lukaszsamson
Copy link
Copy Markdown
Contributor

This PR adds experimental WebTransport support in phoenix using cowboy backend with native quicer HTTP 3 library

Widespread WebTransport adoption on the browser side is still hindered by Safari (support landing on 26.4) (see https://caniuse.com/webtransport), cowboy HTTP 3 support is still immature and on the infra side QUIC traffic is another story so I don't expect this being a big priority soon

This repo https://github.com/lukaszsamson/phoenix_webtransport_demo has a demo app

Screenshot 2026-02-24 at 23 33 10 Screenshot 2026-02-24 at 23 34 18

@lukaszsamson lukaszsamson marked this pull request as draft February 24, 2026 22:40
Copy link
Copy Markdown
Contributor

@SteffenDE SteffenDE left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is interesting for sure, but I don't think we'd go ahead with this without having it also working with Bandit and without it properly handling the auth token (see comment).

On the JS side, you can already pass a custom transport when constructing the socket, so maybe what we could have for the time being is a better way to do custom server side transports without needing all the code in Phoenix itself? (Not sure how to best do that though)

Comment on lines +20 to +22
if(typeof (TextEncoder) !== "undefined"){
return new TextEncoder().encode(text)
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any browser that has WebTransport but no TextEncoder?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems the check is not needed

endpointURL(){
let url = this.toURL(this.endpoint)
if(this.authToken){
url.searchParams.set("auth_token", this.authToken)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that the whole idea behind the auth token is that it's NOT included in query parameters, as those are often part of access logs.

It seems like this is coming at some point: w3c/webtransport#713

@lukaszsamson
Copy link
Copy Markdown
Contributor Author

This is interesting for sure, but I don't think we'd go ahead with this without having it also working with Bandit and without it properly handling the auth token (see comment).

Fair. I treat this PR as an exploration. The tech is not yet ready for wide deployment

On the JS side, you can already pass a custom transport when constructing the socket, so maybe what we could have for the time being is a better way to do custom server side transports without needing all the code in Phoenix itself? (Not sure how to best do that though)

I haven't checked the custom transports so I cant tell they are flexible enough. IMO when the tech matures phoenix would need to adopt it as an officially supported transport

@SteffenDE
Copy link
Copy Markdown
Contributor

IMO when the tech matures phoenix would need to adopt it as an officially supported transport

I agree :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants