Add http & https asset sources

[mrchantey]

Objective

• Fixes Feature: Upstream bevy_web_asset, allowing assets loaded via http #16307

Solution

• Add http & https asset sources

Testing

• Verify visually by running cargo run --example http_source

---

Showcase

Bevy now supports assets loaded via url!

Add the http_source and optionally http_source_cache features.

  // Simply use a url where you would normally use an asset folder relative path
  let handle = asset_server.load("https://raw.githubusercontent.com/bevyengine/bevy/refs/heads/main/assets/branding/bevy_bird_dark.png");
  commands.spawn(Sprite::from_image(handle));

[mrchantey]

It looks like surf and http-cache-surf have failed licence, vunerability & unmaintaned checks. Does that mean they're not allowed as first party dependencies?

[BenjaminBrienen]

It's possible to add an exception for the licenses, but unmaintained and vulnerable is pretty bad.

[mnmaita]

This could be done with something like reqwest maybe to avoid using the unmaintained crates. I successfully ran the example with it but my code is probably bad 😅. I can still push a PR as a showcase in case it serves as inspiration.

[MalekiRe]

Yep this looks awesome to me! Also I wasn't aware of the surf crate; I'll have to keep it in mind for any bevy dashboards I make in the future

[mrchantey]

I can still push a PR as a showcase in case it serves as inspiration.

@mnmaita actually that would be great, I've replaced surf and http-cache-surf with reqwest line for line but am a bit stuck at the moment with reqwest demanding to be run inside a tokio runtime.

// crates/bevy_asset/src/http_source.rs#134

    let client = reqwest_middleware::ClientBuilder::new(Client::new())
        .with(Cache(HttpCache {
            mode: CacheMode::Default,
            manager: CACacheManager::default(),
            options: HttpCacheOptions::default(),
        }))
        .build();

    let response = ContinuousPoll(client.get(str_path).send())
        .await

[jf908]

FWIW surf has a bug where any erroring http response >8kb stops every subsequent request from succeeding and is unlikely to ever be fixed which made me unable to use bevy_web_asset so I would personally appreciate a switch 😄.

If you can't get reqwest to work perhaps hyper would suffice since it's already in the dep tree for BRP? Perhaps too low level for this.

[mrchantey]

The council of bevy async wizards has spoken and we're going with ureq. It doesn't currently have a http-cache wrapper but I've opened an issue and the author might look into creating one when they have time. I guess its worth waiting a bit to see if ureq will get first party support before rolling our own http-cache wrapper, in which case this pr is ready for review :)

A few notes:

• We're still failing check-advisories & check-licences
• I used gh codespaces so wasnt able to cargo run --example http_source, can somebody please try running that?

[github-actions]

You added a new example but didn't add metadata for it. Please update the root Cargo.toml file.

[jf908]

• I used gh codespaces so wasnt able to cargo run --example http_source, can somebody please try running that?

Tested on Windows 11. The example prints a 404 error when the .meta file fails to load and doesn't show the sprite.

If I configure AssetPlugin to AssetMetaCheck::Never, it runs correctly.

I believe the asset is still supposed to load successfully even if the .meta file 404s so I think this is a bug?

[BenjaminBrienen]

We're still failing check-advisories & check-licences
I used gh codespaces

You can ignore that. It isn't a required check. Once those 2 small issues above are fixed, this should be in a pretty good state, I think.

[mrchantey]

Ok I can confirm the example is working in wasm and native builds.

I'm a bit uneasy merging without native http caching. One of the primary use-cases for the feature is large assets and the current implementation wil re-download them every time the app is run. Maybe a stupidly naive cache, ie one that never automatically invalidates, is better than nothing?

In the long run it looks like a http-cache-ureq implementation would be ideal.

[mrchantey]

A simple native cache has been added and is ready for review

[jf908]

I have a couple of concerns but overall looks good. I really want this so I appreciate you spearheading it!

[github-actions]

You added a new feature but didn't update the readme. Please run cargo run -p build-templated-pages -- update features to update it, and commit the file change.

[jf908]

http_source should be added a required feature for the example but otherwise looks good to me