Assets fail to load on the Windows install page (possible SRI issue)

[igorskyflyer]

Both the site's main JS and CSS don't load on the Windows installation page.

URL for broken page

https://git-scm.com/install/windows

Problem

The assets don't load. Upon initial tests on Edge, the following errors are diplayed:

Figure 1. Edge Dev Tools

After the initial test, I've tested on Firefox and Firefox reports it's a SRI issue (for the JS file).

Figure 2. Firefox Dev Tools

Operating system and browser

OS: Windows 11, 25H2, 26200.8246.
Browser:

• Edge v147.0.3912.60 (Official build) (64-bit)
• Mozilla Firefox v149.0.2 (64-bit)

Steps to reproduce

1. Navigate to the provided URL.
2. Notice that the styling of the page and interactivity are broken.
3. Open Dev Tools to observe the error.

Other details

Page screenshot

Figure 3. Screenshot – no styling applied

[dscho]

Doesn't reproduce for me. All I get in the Dev Console is:

Are you sure that this is not a caching problem on your side?

[igorskyflyer]

Doesn't reproduce for me. All I get in the Dev Console is:

Are you sure that this is not a caching problem on your side?

I did test with a forced-reload before posting, same issue.
Also, my DevTools always have caching disabled.

Even tested on my phone, same problem.

[dscho]

Well, when I try this at home, I don't get that href:

$ curl -s https://git-scm.com/install/windows | grep 'application\.min\..*\.js'
<script src="/js/application.min.e1bd0f8cc708294513afeb468b0adece92c865d0e27760b2cd645c2031692d37.js"></script>

By the way, redacting the hash of a downloaded resource is a bit counterproductive when you report an issue with said resource.

[dscho]

None of the "sha256" hashes in the integrity attribute match the content of the subresource at "https://git-scm.com/js/application.min.c8062fe3749fe4e7dbb94e6eb493428df341ca7bd17558c2dc82ed85906d9e6c.js". The computed hash is
REDACTED

None of the "sha256" hashes in the integrity attribute match the content of the subresource at "https://git-scm.com/js/application.min.c8062fe3749fe4e7dbb94e6eb493428df341ca7bd17558c2dc82ed85906d9e6c.js". The computed hash is
REDACTED

And funnily enough, that href doesn't 404 for me:

$ curl -sI https://git-scm.com/js/application.min.c8062fe3749fe4e7dbb94e6eb493428df341ca7bd17558c2dc82ed85906d9e6c.js
HTTP/2 200
date: Tue, 14 Apr 2026 23:31:41 GMT
content-type: application/javascript; charset=utf-8
server: cloudflare
x-origin-cache: HIT
last-modified: Thu, 09 Apr 2026 15:29:05 GMT
access-control-allow-origin: *
etag: W/"69d7c5c1-3b7d"
expires: Tue, 14 Apr 2026 19:54:30 GMT
cache-control: max-age=14400
x-proxy-cache: HIT
x-github-request-id: 5BB6:14D84E:958B54:96B0D2:69DE995D
via: 1.1 varnish
age: 13521
x-served-by: cache-fra-eddf8230230-FRA
x-cache: HIT
x-cache-hits: 1
x-timer: S1776195980.080627,VS0,VE2
vary: Accept-Encoding
x-fastly-request-id: e57009e55cfa82834fc54b40472f9d30d6ade63d
cf-cache-status: HIT
cf-ray: 9ec68167ac321623-DUS

Works. Same for the href that my earlier curl call reported:

$ curl -sI https://git-scm.com/js/application.min.e1bd0f8cc708294513afeb468b0adece92c865d0e27760b
2cd645c2031692d37.js
HTTP/2 200
date: Tue, 14 Apr 2026 23:33:30 GMT
content-type: application/javascript; charset=utf-8
server: cloudflare
x-origin-cache: HIT
last-modified: Tue, 14 Apr 2026 19:45:09 GMT
access-control-allow-origin: *
etag: W/"69de9945-3b7d"
expires: Tue, 14 Apr 2026 19:55:44 GMT
cache-control: max-age=14400
x-proxy-cache: HIT
x-github-request-id: 7BA4:36F698:92B289:93D7F6:69DE998A
via: 1.1 varnish
age: 13602
x-served-by: cache-rtm-ehrd2290021-RTM
x-cache: HIT
x-cache-hits: 1
x-timer: S1776196008.929496,VS0,VE8
vary: Accept-Encoding
x-fastly-request-id: b78dadf83640f924132a1cb08dd39850e4eb2f36
cf-cache-status: HIT
cf-ray: 9ec68410da1ccaf1-DUS

So I really cannot reproduce over here, no matter what I try.

[igorskyflyer]

@dscho,

I understand, if this helps, Firefox even gets served the default 404 page.

Figure 1. Firefox Dev Tools

Anyway, I just wanted to inform you of the issue, maybe another member could try to reproduce this issue if you cannot on your end - if you find it necessary.

[dscho]

if this helps, Firefox even gets served the default 404 page.

Anyway, I just wanted to inform you of the issue, maybe another member could try to reproduce this issue if you cannot on your end - if you find it necessary.

No, it doesn't help. And informing me about an issue I cannot confirm is also not going to help much. And there's no "if" about me not being able to reproduce, especially after I spent a substantial amount of time trying to reproduce here and to figure out whether it could be Cloudflare or something else.