Pre-Fetch Callback for Resource to Support Conditional Headers

[pio-seequent]

Feature

We are currently using the Resource class to manage requests for a tileset. However, in our setup, the tileset and its individual tiles require different HTTP headers for their respective requests. While we have been able to work around this limitation using the retryCallback, this approach feels more like a workaround than an ideal solution.

To address this, we propose adding a pre-fetch callback or a similar mechanism to the Resource class. This callback would allow developers to dynamically modify headers (or other request properties) before a request is made. Such a feature would provide greater flexibility and enable more robust handling of scenarios where headers or other request parameters need to vary based on the specific resource being fetched.

Thank you for considering this request.

[ggetz]

@jjspace Could you please advise and triage? If there's an existing issue which covers a similar topic, let's move the discussion there.

[jjspace]

This is similar to, but I think distinct from, these issues:

• https://github.com/CesiumGS/cesium/issues/12386
• https://github.com/CesiumGS/cesium/issues/10435
• https://github.com/CesiumGS/cesium/issues/11935

All of these get to a sort of core concept of having more control over the extra parameters/headers of a specific Resource and how they're set, updated and propagated among derived Resource instances.

If I understand this issue correctly the initial Resource for a tileset should have 1 set of headers but all subsequent Resource objects for each tile should have a different set of headers? Inside the tile loading logic we clone or reuse the main Resource for a tileset and modify the route slightly. I think this is what's causing issues here?

I could see value in a callback for setting the headers per call especially on derived/cloned Resource instances. However I'm not sure what arguments would make the most sense to pass to it. Any thoughts @pio-seequent? What values would you want to support your use case?

I do also wonder if this is an issue that could be addressed by different tile loading logic or additional options to set a different resource for tiles vs tilesets? Probably a handful of different options to actually address the problem

I'm also curious if this is a common issue, I wouldn't normally expect that tiles load with a different method than the tilesets themselves. Part of me feels a good solution here would also be to change how tiles are hosted/served so they can be accessed the same as the tileset itself. (Doesn't mean we shouldn't still look into this, just curious)

[pio-seequent]

Thank you for the detailed reply!

To clarify, in our setup:

• The tileset JSON is requested via an API endpoint that requires authentication headers.
• The tile content (e.g., .glb, .gltf, etc.) is accessed via signed URLs pointing directly to blob storage, which must not include authentication headers—these requests will fail if the headers are present.

Currently, we use the retryCallback to remove headers for tile content requests, but this is more of a workaround. For our needs, simply being able to modify headers per request (as in a pre-fetch callback) would be sufficient. Alternatively, a way to specify a separate Resource for tile content vs. the tileset would also solve our problem.

That said, we’re open to any other approaches you might recommend—our main goal is to ensure the correct headers are set for each request type.