The logic in stream ID direction detection seems wrong

[KershawChang]

The current logic for determining whether a stream is incoming or not seems incorrect to me.
Specifically, the logic:

webtransport/main/lib/http2/parserbase.js

Line 118 in 3475169

const incoming = this.isclient ? !(streamid & 0x1n) : !!(streamid & 0x1n)

For example, when streamid = 4n:

• This is a client-initiated bidirectional stream.
• If this.isclient === false (i.e., we are the server), this stream should be incoming.
• However, this code returns false.

As I understand it, stream ID 4 should be treated as an incoming stream on the server side.
Am I missing something?

[martenrichter]

The problem seems to be, that I have mixed up server and client initiated streams, see:

webtransport/main/lib/http2/streamidmanager.js

Line 299 in 3475169

getFirstOutgoingStreamId() {

It is also the other way round. (I looked in the spec, client initiated should be even and server odd).
Expect more problems like this in the HTTP/2 code, as there was no second implementation for testing.
I will try to fix it tomorrow.
What gives me a bit of a headache is that my Webtransport Over Websocket code also uses this logic, and I am not sure how I can seamlessly transition the users of my lecture web app.

[martenrichter]

Well, I have ported:
https://github.com/google/quiche/blob/e717f8c12680be5b977f1eb16d85ea94643401db/quiche/quic/core/quic_utils.cc#L425
for streamid management.
I seem to have chosen the wrong version.

[martenrichter]

Ok, I have made a patch.
But I will not merge it, as it is a breaking change in protocol, and I assume that you will find additional issues.
The plan is to merge it and do a second major release once you tell me that it seems to speak a compatible http/2 web transport to Firefox.
Until then, you can use the branch http2fix .

Btw. do you know the local testing feature of this package:
w3c/webtransport#622
for http/2, you have to start it with an added 'http2' to the startup command line.

Is there already a http/2 web transport implementation in nightly?

[KershawChang]

Ok, I have made a patch. But I will not merge it, as it is a breaking change in protocol, and I assume that you will find additional issues. The plan is to merge it and do a second major release once you tell me that it seems to speak a compatible http/2 web transport to Firefox. Until then, you can use the branch http2fix .

Btw. do you know the local testing feature of this package: w3c/webtransport#622 for http/2, you have to start it with an added 'http2' to the startup command line.

Is there already a http/2 web transport implementation in nightly?

The feature is still under development.
You can track progress through this bug. Thank you!

[RealTimeCom]

I do not see HTTP/3 :method GET in setRequestCallback() HTTP function handler, and the server responds with default 404 file not found.
Only :method CONNECT is handled by setRequestCallback() ? there is no way to handle GET requests by Http3Server ?

Thanks!

[martenrichter]

@RealTimeCom That is offtopic as the issue is http2 only. Regarding http/3 this is a webtransport only implementation, so only webtransport relevant parts of http/3 are handled. So there is no intention to support things besides wt, such as the usual get, put etc. requests.

[KershawChang]

Hi @martenrichter , just a quick update — the WebTransport over HTTP/2 project is currently paused because we’ve had to shift focus to higher-priority work. Once the project resumes, I’ll come back and test your fix. Thanks.

[martenrichter]

@KershawChang Thanks for the update. I hope it resumes soon....