client.doRequest reads responses through io.ReadAll(io.LimitReader(resp.Body, maxResponseSize)) with maxResponseSize = 10 << 20. When a body exceeds 10 MiB the reader returns a truncated byte slice with err == nil, so GetJSON passes a partial document to json.Unmarshal and the caller sees unexpected end of JSON input with no hint that a size cap was hit.
Hit in the wild via pin: the npm tailwindcss packument is 10,499,105 bytes. See git-pkgs/pin#2.
Suggested:
- Read
maxResponseSize+1 and return an explicit error (response body for %s exceeds %d bytes) when the extra byte arrives, rather than returning truncated bytes.
- Expose the cap as an
Option (e.g. WithMaxResponseSize(int64)) so callers that legitimately need large bodies (npm full packuments can approach 100 MB) can raise it per-client.
10 MiB is a reasonable default for most registry metadata; the problem is the failure mode, not the number.
client.doRequestreads responses throughio.ReadAll(io.LimitReader(resp.Body, maxResponseSize))withmaxResponseSize = 10 << 20. When a body exceeds 10 MiB the reader returns a truncated byte slice witherr == nil, soGetJSONpasses a partial document tojson.Unmarshaland the caller seesunexpected end of JSON inputwith no hint that a size cap was hit.Hit in the wild via pin: the npm
tailwindcsspackument is 10,499,105 bytes. See git-pkgs/pin#2.Suggested:
maxResponseSize+1and return an explicit error (response body for %s exceeds %d bytes) when the extra byte arrives, rather than returning truncated bytes.Option(e.g.WithMaxResponseSize(int64)) so callers that legitimately need large bodies (npm full packuments can approach 100 MB) can raise it per-client.10 MiB is a reasonable default for most registry metadata; the problem is the failure mode, not the number.