Add http & https asset sources (clean commit history)

[mrchantey]

Objective

This is a duplicate of #16366 because I made a mess of the commit history. See that pr for more context and discussion.

• Fixes Feature: Upstream bevy_web_asset, allowing assets loaded via http #16307
• Closes Add http & https asset sources #16366

Solution

• Add http & https asset sources
• Allows CDLA-Permissive-2.0 in deny.toml

Testing

• Verify visually by running cargo run --example http_source --features="http_source"

---

Showcase

Bevy now supports assets loaded via url!

Add the http_source feature to load assets served over the web, with support for both native and wasm targets. On native targets the http_source_cache feature will use a basic caching mechanism to avoid repeated network requests.

  // Simply use a url where you would normally use an `assets` 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));

Further Work

• Better AssetReaderError: The asset path is not always collected in the error. This is likely a common error that actual non-developer users will see so its important to get it right.
• Possibly expose the native request mechanic as a general fetch, in the future we'll have many reasons to be making requests.

[Elabajaba]

Just a quick note, ring is now unmaintained for the foreseeable future.

[recatek]

Adding MPL as an allowed license seems like it would have complications for distributing game binaries, no?

That said, I'm not clear what new dependency here actually requires it. Both ureq and webpki-roots support MIT and Apache 2.0 from looking at their repos.

[mockersf]

Just a quick note, ring is now unmaintained for the foreseeable future.

ring is maintained again, now by the rustls team

[mockersf]

blocked on finding where the MPL license comes from and removing it

[mockersf]

waiting on a new release of webpki-root with this commit: rustls/webpki-roots@90c48f3#diff-8aec0a2c31031e00524df726f854726660ec8289dcddfa70005000fc21b00511

[jf908]

As of right now, ring is not actually included in this PR, it was replaced by aws-lc-rs. Now that ring has removed the OpenSSL parts of the license, I think we can remove aws-lc-rs, remove OpenSSL from deny.toml and use the ureq's default ring dependency again. This would be especially nice because aws-lc-rs requires installing CMake on Windows.

[mrchantey]

I agree, more iteration is requried but this pr is already substantial. How about we create a follow-up issue for discussion on whats needed to complete http asset sources and open smaller prs from there.

[alice-i-cecile]

I've spoken with @cart about this, and we'd like to move forward with this as a solution for example assets (in addition to thinking it's broadly useful). We just need a second approval now to get this merged.

[mockersf]

similar to how the file asset source exposes only a directory and not the whole filesystem, I think an https source should only allow access to a domain and not the whole internet

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

similar to how the file asset source exposes only a directory and not the whole filesystem, I think an https source should only allow access to a domain and not the whole internet

I am quite biased towards allowing more than 1 origin because I’m currently making a bevy game where not all my assets are hosted over the same server. Otherwise I see the upside of being able to neatly switch out the asset server host name but there’s also the downside that we would lose the neatness of the asset path being the URL.

Do you think a config option to specify allowed host names would be a good alternative?

[jf908]

I have given this some more thought and I'm starting to turn around to the idea.

I don't think a config option for allowed host names would be that useful since its quite easy to parse the url and do any checking you want manually before you load an asset.

I didn't know this until now but file assets can be loaded from absolute paths but they will be rejected unless unapproved_path_mode is set accordingly. We could probably do the same for web assets by having the same unapproved_path_mode option to allow access to the entire internet if required. The main problem I see is that relative paths already default to the file system and afaik there is no common syntax to define a relative http URL so we would have to come up with our own syntax which doesn't clash with absolute http URLs which I don't think would be very intuitive.

Another issue is that unlike the assets folder, there is no sensible default origin. If we want to force people to pick an origin (which would be good practice), we wouldn't be able to make the Plugin Default and that would make it annoying to construct (in the future when it has many config options).

[mockersf]

If we want to force people to pick an origin (which would be good practice), we wouldn't be able to make the Plugin Default and that would make it annoying to construct (in the future when it has many config options).

I think this is more a feature than an issue. Having to opt in to http on a specific domain is a better way to use it in my opinion. If the number of config options becomes too large, we can either rely on a default implementation for most options, or a builder pattern