Stale API responses in Blazor WebAssembly HttpClient

Direct answer

No. Blazor WebAssembly HttpClient does not expose a native API to bypass the browser cache. The WASM HttpClient is a thin wrapper over the browser Fetch API, so caching is controlled by the browser and by HTTP response headers, not by Blazor.

You can avoid query-string workarounds by controlling caching at the HTTP layer:

• Set response headers on the API so the browser never serves a stale copy.
• Set default request headers from the WASM client via a delegating handler so every HttpClient call asks for revalidation.

There is no HttpClient option to set fetch cache mode from WASM code.

Confirmed facts

• Blazor WASM HttpClient delegates to the browser Fetch API. Cache-Control, ETag and Last-Modified are honored by the browser.
• Request headers can be added to HttpClient. Response headers are set by the server.
• Cache-Control: no-store tells the browser not to store a response in any cache. Cache-Control: no-cache tells the browser to revalidate with the origin before using a cached copy.

Likely explanation for stale UI on OnInitializedAsync

The browser may return a response from memory or disk cache for a GET request that is considered fresh. OnInitializedAsync runs again but the fetch is satisfied locally, so the UI shows old data even though the component state reset. This is browser behavior, not a Blazor bug.

Difference between no-cache and no-store from WASM

Both are request/response headers interpreted by the browser engine. From the WASM runtime there is no difference in how they are sent.

• no-cache: browser must revalidate with the origin using conditional requests. If the server returns 304 Not Modified, the cached body can still be used. This still involves a network round-trip for validation.
• no-store: browser must not write the response to disk or memory cache at all, and must not read from cache. Every request should result in a full network fetch.

Enforcement is not perfectly consistent across Chromium, WebKit and Gecko, and can be altered by service workers, offline manifests, or intermediate proxies.

Minimal steps for this case

1. Server side. Return for data endpoints:

   Cache-Control: no-store, no-cache, must-revalidate
   Pragma: no-cache
   Expires: 0

2. Client side default request header via a delegating handler, registered once at app startup:

   public class NoCacheHandler : DelegatingHandler
   {
     protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken ct)
     {
       request.Headers.CacheControl = new System.Net.Http.Headers.CacheControlHeaderValue { NoCache = true };
       return base.SendAsync(request, ct);
     }
   }

3. Verify in the browser Network tab. Look for the request headers you set and the response headers from the API. Confirm the response is not marked "from cache" and that a network request occurs on each OnInitializedAsync.

One diagnostic that changes the recommendation: is a service worker registered for the Blazor app? A service worker can intercept fetch and override Cache-Control. If present, header changes alone may not be sufficient and the service worker cache strategy must be updated.