WebTransport ignores query parameters in URL

[weary-adventurer]

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)
	);
	}

[darrachequesne]

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:

• https://developer.mozilla.org/en-US/docs/Web/API/WebTransport
• https://w3c.github.io/webtransport/#web-transport

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?

[weary-adventurer]

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