security-union / sec-http3

MIT License
14 stars 0 forks source link

add Mozilla Firefox support #7

Open darioalessandro opened 11 months ago

cybersoulK commented 11 months ago

Error in firefox:

h3::Error { code: H3_STREAM_CREATION_ERROR, reason: "Stream closed before type received" }

seems like if i comment either of these lines (Client side), it avoid the error: (but streams don't work)

writer.release_lock();
JsFuture::from(stream.close()).await.unwrap();

OR

I can comment out BOTH of these lines in the server, and avoid the error:

session.accept_uni() => ...
session.accept_bi() => ...

so basically streams has some issues. Datagrams seem to work fine.

darioalessandro commented 11 months ago

@ten3roberts ^^ what do you think? any clues?

darioalessandro commented 11 months ago

I feel that we need an echo test for your sec-http3 webtransport implementation.

I tested my client code in mozilla with a public webtransport echo test and it works great:

https://security-union.github.io/yew-webtransport/

Screenshot 2023-07-12 at 7 50 49 AM

darioalessandro commented 11 months ago

@cybersoulK can you test my echo client against your backend?

ten3roberts commented 11 months ago

I've seen this one before.

It is a bug in h3 related to buffering. When the AcceptRecvStream future is polled it polls the underlying stream to fetch the available data into a buffer, and then tries to parse the buffer into a frame header. It will try multiple because sometimes the data which has arrived is not yet a full header.

The issue is that it will first poll the stream, and in doing so return that the stream is closed, before checking if there is buffered data available.

It can be reproduced by sending an empty message (i.e just a a frame header) on the chrome echo client as well.

cybersoulK commented 9 months ago

To add some valuable information from my testing on Firefox:

Datagrams work fine. Uni streams Server->Client works perfect.

The issue: When client sends uni streams to the server. the first several streams are successful. And then there is an error:

my logs:

 1st stream: Success: JsFuture::from(uni_stream)

 2nd stream: Error: JsFuture::from(uni_stream) failed: JsValue(InvalidStateError: An attempt was made to use an object that is not, or is no longer, usable

error:

Uncaught (in promise) TypeError: getObject(...) is undefined
https://localhost/client.js

so there is something external affecting it. perhaps the server rejects the first unidirectional streams and closes the connection.

(client -> server bidirectional streams works fine, so that's weird)

cybersoulK commented 9 months ago

I feel that we need an echo test for your sec-http3 webtransport implementation.

I tested my client code in mozilla with a public webtransport echo test and it works great:

https://security-union.github.io/yew-webtransport/

@darioalessandro

when i connect the echo client on Firefox to my backend:

16:34:36.191: Connection lost (JsValue(Object({"closeCode":0,"reason":""}))) 16:34:36.188: Sending: "awdawdawdwad" using UnidirectionalStream 16:34:34.191: Sending: "awdawdawdwad" using Datagram 16:34:33.903: Sending: "awdawdawdwad" using Datagram 16:34:33.597: Sending: "awdawdawdwad" using Datagram 16:34:33.129: Sending: "awdawdawdwad" using Datagram 16:34:30.055: Sending: "awdawdawdwad" using BidirectionalStream 16:34:28.508: Sending: "awdawdawdwad" using BidirectionalStream 16:34:27.917: Sending: "awdawdawdwad" using BidirectionalStream