Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add Mozilla Firefox support #7

Open
darioalessandro opened this issue Jul 10, 2023 · 7 comments
Open

add Mozilla Firefox support #7

darioalessandro opened this issue Jul 10, 2023 · 7 comments

Comments

@darioalessandro
Copy link
Member

No description provided.

@cybersoulK
Copy link

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
Copy link
Member Author

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

@darioalessandro
Copy link
Member Author

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
Copy link
Member Author

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

@ten3roberts
Copy link
Collaborator

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
Copy link

cybersoulK commented Sep 9, 2023

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
Copy link

cybersoulK commented Sep 9, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants