Stale API responses in Blazor WebAssembly HttpClient

Blazor WebAssembly applications utilizing HttpClient for data retrieval rely on the browser's native Fetch API. This architecture means that responses are subject to standard HTTP caching headers, such as Cache-Control and ETag.

When a component triggers OnInitializedAsync, the browser may resolve the request internally from the disk or memory cache rather than performing a network round-trip. This leads to the UI displaying stale data even after the application state has theoretically reset.

There is uncertainty regarding the consistent enforcement of Cache-Control: no-cache across different browser engines when these headers are managed via the WASM HttpClient implementation.

• Does the Blazor WASM HttpClient provide a mechanism to bypass the browser cache without manually appending unique query strings to every request?
• How does the browser's handling of no-cache versus no-store differ when requests are initiated from the WASM runtime?