WebTransport ignores query parameters in URL

Describe the bug
The final WebTransport URL doesn't include the query parameters from the original URL.

To Reproduce

engine.io-client 6.6.4

Client

// Connects to: https://localhost:1234/engine.io/?x=y&EIO=4&transport=polling&t=zsyh7czl 
eio("https://localhost:1234/?x=y", {transports: ["polling"]});

// Connects to: wss://localhost:1234/engine.io/?x=y&EIO=4&transport=websocket
eio("https://localhost:1234/?x=y", {transports: ["websocket"]});

// Connects to: https://localhost:1234/engine.io/
eio("https://localhost:1234/?x=y", {transports: ["webtransport"]});

Expected behavior
The WebTransport transport should preserve the query parameters in the same way other transports do.

Additional context

WebTransport currently uses createUri to construct the URL:

socket.io/packages/engine.io-client/lib/transports/webtransport.ts

Lines 31 to 34 in 439a8f6

    
           this._transport = new WebTransport( 
        
             this.createUri("https"), 
        
             this.opts.transportOptions[this.name], 
        
           );

It doesn't include the original query parameters:

socket.io/packages/engine.io-client/lib/transport.ts

Lines 176 to 185 in 439a8f6

    
           protected createUri(schema: string, query: Record<string, unknown> = {}) { 
        
             return ( 
        
               schema + 
        
               "://" + 
        
               this._hostname() + 
        
               this._port() + 
        
               this.opts.path + 
        
               this._query(query) 
        
             ); 
        
           }

Hi! Thanks for raising this important issue.

Query parameters were indeed not included in the initial implementation, because the WebTransport API itself does not expose query parameters as a first-class property on the WebTransport object/session.

References:

So it is up to the server implementation to decide how to expose them.

The current implementation (@fails-components/webtransport) lets the user retrieve the query parameters with the setRequestCallback() method.

Reference: fails-components/webtransport#448

But the future Node.js WebTransport server implementation may land on a different API...

So we definitely could include them on the client side like you suggest in your pull request, but they won't be used for now on the server side. What do you think?

For WebTransport I currently use my own implementation and pass in a net.Socket wrapped as a stream to eio.onWebTransportSession. The WebTransport session is initially accepted by a reverse proxy outside of the Node.js process that cares about the extra query parameters in the initial URL. The pull request you've mentioned is not made by me but someone else who saw this issue, if it makes the original query be included on the webtransport request then it's a good idea to send it (and have it be unused on the server side).

fix(engine.io-client): pass query params to createUri in WebTransport

Note: a client-only fix (such as #5499) is not sufficient with the current @fails-components/webtransport integration, because the HTTP/3 server matches the session path literally. If the client connects to:

/engine.io/?x=y&EIO=4&transport=webtransport

then sessionStream("/engine.io/") will not match unless the request callback strips the query string and forwards the parsed query somewhere else.

Navigation Menu

Repository navigation

WebTransport ignores query parameters in URL #5496

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	this._transport = new WebTransport(
	this.createUri("https"),
	this.opts.transportOptions[this.name],
	);

	protected createUri(schema: string, query: Record<string, unknown> = {}) {
	return (
	schema +
	"://" +
	this._hostname() +
	this._port() +
	this.opts.path +
	this._query(query)
	);
	}

WebTransport ignores query parameters in URL #5496

Description

Activity

darrachequesne commented on May 28, 2026

weary-adventurer commented on May 28, 2026

darrachequesne commented on Sep 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions