quiche: Why cant webtransport trigger http3 data event?

I changed the headers in accordance to https://github.com/cloudflare/quiche/issues/1132#issuecomment-1018293465 and the connection got established in https://googlechrome.github.io/samples/webtransport/client.html. But when I send a bidirectional stream, the event quiche::h3::Event::Data is not triggered. I think the bidirectional frame has this format: https://www.ietf.org/id/draft-ietf-webtrans-http3-02.html#name-bidirectional-streams. Any help would be appreciated.

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 15 (7 by maintainers)

Most upvoted comments

WebTransport streams are not HTTP/3 requests or response. WebTransport rewrites the rules for bidirectional streams, see https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3-02#section-4.2, and quiche’s HTTP/3 layer does not support other things redefining the rules. So fighting against quiche is not going to be a path to fulfillment.

I suspect it is some extra data that quiche is sending that is required by the http3 protocol, but webtransport is perhaps parsing it as payload data.

Yes, this is the DATA frame, which is how request and response body is sent - https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-34#section-7.2.1

If you just want to experiment, then it would suffice to service the Extended CONNECT request for session establishment and then start using quiche’s stream_send()/stream_recv() directly. This is, however, not a very sustainable long-term solution. Instead, quiche’s h3 layer should be modified as I already mentioned.

Hi @kalradivyanshu, nice to see you experimenting with WebTransport here! Do you keep a public fork with your modifications for WebTransport? I’m interested in checking this out, too! Cheers

The congestion control and flow control aspect should be common no matter what happens at the application. You’ll have some capacity to send with, and stream_send() will consume it. The only way to get more is to send and receive packets to/from the peer. If you get the sequence right, then it’s possible to get use most of the available network capacity. Once in the 10 gigabit/s other factors start to come into play.

If the client is getting blocked on the server, be sure that you are reading out stream data sufficiently. That will return flow control credit and you’ll again need to send QUIC packets so the client actually gets them, otherwise the client will get flow control blocked.

Ok, so I was able to make send_body() work, the problem was I hadnt initialized the local part of the stream, so this condition was being hit: (https://github.com/cloudflare/quiche/blob/master/quiche/src/h3/mod.rs#L1000)

if !s.local_initialized() {
    return Err(Error::FrameUnexpected);
}

However I am receiving some extra bytes in the webtransport chrome example. If I send [u8] containing [119, 119, 119] I receive in chrome [0, 3, 119, 119, 119]. I suspect it is some extra data that quiche is sending that is required by the http3 protocol, but webtransport is perhaps parsing it as payload data.

Why would this be happening? Any insights into whats going on?