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

Bevy 0.12, ehttp + low level wasm #19

Closed
wants to merge 8 commits into from
Closed

Conversation

johanhelsing
Copy link
Owner

@johanhelsing johanhelsing commented Nov 19, 2023

alternative to #18

This isn't pretty, but at least it:

  • Has no regression I know of
  • Doesn't use abandoned crates
  • Doesn't freeze when fetching things from my s3 server

@voidentente
Copy link
Contributor

* Doesn't freeze when fetching things from my s3 server
2023-11-19T07:39:38.175049Z  INFO bevy_web_asset::web_asset_source: fetching https://s3.johanhelsing.studio/dump/favicon.png
2023-11-19T07:40:08.202203Z  INFO bevy_web_asset::web_asset_source: callback
2023-11-19T07:40:08.202243Z  INFO bevy_web_asset::web_asset_source: something
2023-11-19T07:40:08.202290Z ERROR bevy_asset::server: encountered an io error while loading asset: https://s3.johanhelsing.studio/dump/favicon.png: Network Error: timed out reading response

Anyway, this is in line with what I had in mind for the wasm backend as well. But why use ehttp if you don't use its wasm backend? Might as well use ureq directly.

@johanhelsing
Copy link
Owner Author

That's so weird... What OS are you on? And just to confirm, this used to work with surf?

Also totally agree about using ureq directly is better. Feel free to take over!

@voidentente
Copy link
Contributor

Arch Linux. I believe surf and reqwest worked. ureq and minreq don‘t. So you‘re saying these crates don‘t have that problem on your end?

@johanhelsing
Copy link
Owner Author

No they don't. I've only tried ehttpn(this branch though)

@johanhelsing
Copy link
Owner Author

I have arch on my laptop, but don't have time to test until a couple of days

@voidentente
Copy link
Contributor

While it‘s concerning that it‘s inconsistent, it‘s clearly a bug and probably shouldn‘t influence the decision on which client to use. Right now, making at least the native backend non-blocking seems more important; regarding that, please see my latest comment in the other PR.

@voidentente
Copy link
Contributor

voidentente commented Nov 20, 2023

Update: I figured that maybe it could be a problem because those two crates use rustls as default, but it turns out the time-out happens on TCP level.

use std::net::{TcpStream, ToSocketAddrs};
use std::time::Duration;

let addr = "s3.johanhelsing.studio:80"
    .to_socket_addrs()
    .unwrap()
    .next()
    .unwrap();
let _stream = TcpStream::connect_timeout(&addr, Duration::from_secs(4)).unwrap();
println!("connected");

called Result::unwrap()on anErr value: Error { kind: TimedOut, message: "connection timed out" }

Which is kind of obvious to happen, since the domain alone returns no connection on either 80 or 443 without a path.

Example:

s3.johanhelsing.studio:80/dump/favicon.png establishes a connection, while s3.johanhelsing.studio:80 does not.

@johanhelsing
Copy link
Owner Author

johanhelsing commented Nov 20, 2023

Maybe I'm just stupid, but how could you add a path on the tcp level?

Also, that example for me just prints "connected", but I guess that's to be expected, since it works for me anyway.

EDIT: I tested it on arch as well, and it prints connected there as well.

and the web_image example also works on arch for me...

@voidentente
Copy link
Contributor

voidentente commented Nov 20, 2023

Maybe I'm just stupid, but how could you add a path on the tcp level?

You can't, because that's a HTTP thing.

The only commonality I'm seeing is that ureq and minreq use std::net::TcpStream, while surf and reqwest use their own, async TcpStream.

EDIT: I have tried it on my laptop and it cannot connect either, so it's probably not a platform problem, but a network problem. Where do you host this server? Are you in the same network as this server? I think it might be useful to get the result of a third party.

@johanhelsing
Copy link
Owner Author

You can't, because that's a HTTP thing.

I’m just confused because you said

s3.johanhelsing.studio:80/dump/favicon.png establishes a connection, while s3.johanhelsing.studio:80 does not.

If the problem is at the tcp level, why does the path matter?

They’re not on the same network. I tried on my machine at work and no problems with TcpStream there either.

Where do you host this server? Are you in the same network as this server? I think it might be useful to get the result of a third party.

It's a digital ocean droplet running an nginx reverse proxy to a minio docker container

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

Successfully merging this pull request may close these issues.

2 participants