fix "browser" test

[krampstudio]

Note

Medium Risk
Touches WebBlob.create header parsing and test fetch behavior; failures would affect streamed/ranged downloads, but changes are small and add validation to reduce silent misbehavior.

Overview
Fixes browser-side WebBlob creation when Content-Length is missing or not usable by validating the content-length header and throwing a clearer error (including x- headers) instead of silently producing an invalid size.

Updates WebBlob tests to avoid relying on CORS-exposed HEAD headers by deriving size from a GET body and injecting a custom fetch that supplies content-length/accept-ranges for the HEAD request. Adds a root lint-staged config to run oxfmt on staged *.{cjs,ts} files.

^{Reviewed by Cursor Bugbot for commit 015531a. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coyotte508]

this fixes the test, but does the problem happen in prod or not?

From a different origin

[krampstudio]

this fixes the test, but does the problem happen in prod or not?

From a different origin

My understanding was that it has already a fallback to a GET in prod when the HEAD was failing or the Content-Length at 0:

huggingface.js/packages/hub/src/utils/WebBlob.ts

Lines 34 to 41 in 1b32a04

	const size = Number(response.headers.get("content-length"));
	const contentType = response.headers.get("content-type") || "";
	const supportRange = response.headers.get("accept-ranges") === "bytes";
	if (!supportRange || size < (opts?.cacheBelow ?? 1_000_000)) {
	return await (await customFetch(url)).blob();
	}

(I will prevent a NaN here btw to be 100% sure)

[coyotte508]

this fixes the test, but does the problem happen in prod or not?
From a different origin

My understanding was that it has already a fallback to a GET in prod when the HEAD was failing or the Content-Length at 0:

huggingface.js/packages/hub/src/utils/WebBlob.ts

Lines 34 to 41 in 1b32a04

	const size = Number(response.headers.get("content-length"));
	const contentType = response.headers.get("content-type") || "";
	const supportRange = response.headers.get("accept-ranges") === "bytes";
	if (!supportRange || size < (opts?.cacheBelow ?? 1_000_000)) {
	return await (await customFetch(url)).blob();
	}

(I will prevent a NaN here btw to be 100% sure)

Ideally though, to avoid downloading the whole blob in memory, CORS issue should be fixed / mitigated in a better way

(finding the root cause is already very nice)

[krampstudio]

Ideally though, to avoid downloading the whole blob in memory, CORS issue should be fixed / mitigated in a better way

(finding the root cause is already very nice)

back on this

The only solution I see is to always use GET and cancel reading the body if the server send the accept-ranges header. The downside is the cancel that can be late and we'll start receiving data.
Something like this:

  const size = Number(response.headers.get("content-length") || 0);
  const contentType = response.headers.get("content-type") || "";
  const supportRange = response.headers.get("accept-ranges") === "bytes";

  if (supportRange && size >= (opts?.cacheBelow ?? 1_000_000)) {
    await response.body?.cancel();
    return new WebBlob(url, 0, size, contentType, true, customFetch, opts?.accessToken);
  }

  return response.blob();

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit af35c19. Configure here.}