Bevy 0.12, ehttp + low level wasm

[johanhelsing]

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]

* 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]

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]

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]

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

[johanhelsing]

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

[voidentente]

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]

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");

calledResult::unwrap()on anErrvalue: 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]

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]

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]

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