Laravel documentation serving stale Cloudflare 404 for CSS asset

[M4tt1-Coder]

The Laravel documentation site is currently intermittently serving a stale 404 response for one of its CSS assets, causing the documentation to render without styling.

Affected asset:

https://laravel.com/build/assets/app-DJTk9ZRw.css

A normal request to the asset returns:

HTTP/2 404
content-type: text/html; charset=utf-8
cache-control: private, max-age=31536000
server: cloudflare
laravel-cloud-cache: DYNAMIC
cf-cache-status: HIT
age: ~25000
x-content-type-options: nosniff
cf-ray: a39325dade2965a5-FRA

This results in the browser error:

The resource from “https://laravel.com/build/assets/app-DJTk9ZRw.css” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff).

However, the same asset is available from the origin. When requesting it with a cache-busting query parameter:

https://laravel.com/build/assets/app-DJTk9ZRw.css?bypass=1

the response is:

HTTP/2 200
content-type: text/css; charset=utf-8
content-length: 603613
last-modified: Thu, 10 Sep 2026 19:13:30 GMT
server: cloudflare
cf-cache-status: MISS
cache-control: max-age=31536000

So it appears that Cloudflare currently has a cached 404 for the canonical asset URL, while the origin correctly serves the CSS.

Could the cached 404 be purged, and could the deployment/cache configuration be checked to determine why the missing-asset response was cached?

This is currently causing the Laravel documentation UI to load without its CSS for affected requests.

Thanks!

[HenryCauan]

The headers already point to an edge-cache problem: the canonical URL returns a cached 404 (cf-cache-status: HIT, large age), while adding a query string reaches the origin and returns 200 text/css.

The immediate fix is to purge the exact asset URL from Cloudflare and verify it from more than one location. For the deployment configuration, avoid caching error responses for hashed static assets, and only apply the long-lived immutable cache policy when the origin returns a successful asset response.

As a temporary client-side workaround, the documentation deployment could reference the same hashed file with a cache-busting query parameter, but the durable fix is purging the stale 404 and correcting the cache rule. The next deploy should also generate a new asset filename so browsers and edge caches do not reuse the bad response.