fix(ui): detect gzip by magic numbers instead of Content-Type header in html reporter

[Copilot]

• closes html reporter not working when metadata served with content-encoding of 'gzip' #9276
• closes fix: fix html reporter binary file extension #9277 (supersedes)

Fix HTML reporter when metadata served with Content-Encoding: gzip

Issue: HTML reporter fails when server sets Content-Encoding: gzip header on html.meta.json.gz, because browser auto-decompresses but code tries to decompress again, causing "invalid distance" errors.

Solution: Check for gzip magic numbers (0x1f 0x8b) in response data instead of relying solely on Content-Type header to determine if decompression is needed.

Plan

• Analyze the issue and understand the problem
• Update registerMetadata() function in packages/ui/client/composables/client/static.ts to check gzip magic numbers
• Run linting and type checking
• Build the UI package successfully
• Code review - no issues found
• Security scan - no vulnerabilities found
• Address PR feedback - clarify comment about incorrect server behavior
• Commit and finalize changes

Changes Made

• Modified packages/ui/client/composables/client/static.ts:
  • Removed Content-Type header check
  • Added gzip magic number detection (0x1f 0x8b)
  • Now always reads response as ArrayBuffer
  • Decompresses only if magic numbers are present
  • Otherwise parses content directly as JSON
  • Updated comment to clarify that server behavior is incorrect

This fix handles both scenarios:

1. Browser auto-decompresses (Content-Encoding: gzip - incorrect server config) → no magic numbers → parse directly
2. File is truly gzipped (Content-Type: application/gzip) → magic numbers present → decompress then parse

Alternative Approaches Considered

• res.clone(): Would read content twice, wasting resources
• res.body.tee(): Added complexity without benefit for small metadata files
• Current approach: Optimal for our use case - single read, simple logic, standard magic number detection

Security Summary

No security vulnerabilities were discovered or introduced by this change.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>html reporter not working when metadata served with content-encoding of 'gzip'</issue_title>
<issue_description>### Describe the bug

If the html.meta.json.gz file is served with the Content-Encoding: gzip headers, then the HTML report doesn't work.

This can happen when trying to display the HTML report on CI/CD like Jenkins which might be configured in a way that adds the Content-Encoding: gzip header when serving the html.meta.json.gz file.

Reproduction

A simple reproduction with express:

import path from 'node:path';
import express from 'express';
import compression from 'compression';

const app = express();

// Enable gzip compression
app.use(compression({ 
    filter: (req, res) => {
        if (req.url.endsWith(".gz")) {
            res.setHeader("Content-Encoding", "gzip");
            return true;
        }
        return compression.filter(req, res);
    }
}));

app.use(express.static(path.join('html'))); // set this to the HTML report directory

app.listen(3000, '0.0.0.0', () => {
  console.log('App listening on port 3000');
});

When loading the report in the browser:

Exception is thrown in the console:

index-DnyN8l5D.js:44 Uncaught (in promise) Error: invalid distance
    at dp (index-DnyN8l5D.js:44:44802)
    at fce (index-DnyN8l5D.js:44:45468)
    at pce (index-DnyN8l5D.js:44:45773)
    at c (index-DnyN8l5D.js:44:47507)

This is because the HTML report Vue application tries to decompress the response again, but the browser already automatically decompressed it.

I think the code in this function should be rewritten:

vitest/packages/ui/client/composables/client/static.ts

Line 99 in b46d744

async function registerMetadata() {

My suggestion is something like this (obviously needs testing):

async function registerMetadata() {
  const res = await fetch(window.METADATA_PATH!)
  const content = new Uint8Array(await res.arrayBuffer());

  if (content.length >= 2 && content[0] === 0x1f && content[1] === 0x8b) {
    // we have gzip magic numbers, decompress
    const decompressed = strFromU8(decompressSync(content));
    metadata = parse(decompressed) as HTMLReportMetadata;
  } else {
    metadata = parse(strFromU8(content)) as HTMLReportMetadata;
  }
  const event = new Event('open')
  ctx.ws.dispatchEvent(event)
}

Another solution of course is to change the web server used by Jenkins to NOT add the Content-Encoding: gzip header when serving an existing file with the .gz extension, but unfortunately I don't control the Jenkins configuration.

System Info

System:
    OS: Linux 5.15 Ubuntu 24.04.3 LTS 24.04.3 LTS (Noble Numbat)
    CPU: (32) x64 AMD Ryzen 9 5950X 16-Core Processor
    Memory: 12.28 GB / 15.58 GB
    Container: Yes
    Shell: 5.2.21 - /bin/bash
  Binaries:
    Node: 24.11.1 - /usr/bin/node
    Yarn: 1.22.22 - /mnt/c/Users/dezsi/AppData/Roaming/npm/yarn
    npm: 11.6.2 - /usr/bin/npm
    pnpm: 10.24.0 - /mnt/c/Users/dezsi/AppData/Roaming/npm/pnpm
  npmPackages:
    @vitest/browser-playwright: 4.0.14 => 4.0.14 
    @vitest/ui: 4.0.14 => 4.0.14 
    vitest: 4.0.14 => 4.0.14

Used Package Manager

npm

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.</issue_description>

Comments on the Issue (you are @copilot in this section)

@hi-ogawa I agree the current Vitest side trick is brittle, but I think technically your server responding with - content-encoding: gzip - content-type: application/gzip

is incorrect. content-type should be application/json since that's the result when browser natively handles decompression. That's what Vitest client assumes around the code of registerMetadata.</comment_new>

• Fixes html reporter not working when metadata served with content-encoding of 'gzip' #9276

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.