valyala/fasthttp · error

too large hex number

Error message

too large hex number

What it means

errTooLargeHexNum is returned by readHexInt in bytesconv.go when parsing a hexadecimal integer (typically a chunked-transfer chunk size) whose value overflows an int. fasthttp aborts parsing because the wire data does not fit a valid integer, so the response/request is treated as malformed.

Source

Thrown at bytesconv.go:369

// ParseUfloat parses unsigned float from buf.
func ParseUfloat(buf []byte) (float64, error) {
	// The implementation of parsing a float string is not easy.
	// We believe that the conservative approach is to call strconv.ParseFloat.
	// https://github.com/valyala/fasthttp/pull/1865
	res, err := strconv.ParseFloat(b2s(buf), 64)
	if res < 0 {
		return -1, errors.New("negative input is invalid")
	}
	if err != nil {
		return -1, err
	}
	return res, err
}

var (
	errEmptyHexNum    = errors.New("empty hex number")
	errTooLargeHexNum = errors.New("too large hex number")
)

func readHexInt(r *bufio.Reader) (int, error) {
	var k, i, n int
	for {
		c, err := r.ReadByte()
		if err != nil {
			if err == io.EOF && i > 0 {
				return n, nil
			}
			return -1, err
		}
		k = int(hex2intTable[c])
		if k == 16 {
			if i == 0 {
				return -1, errEmptyHexNum
			}
			if err := r.UnreadByte(); err != nil {

View on GitHub (pinned to c96f600972)

Solutions

1. Fix or stop using the peer that emits the oversized hex value — the sender's chunked encoding is malformed
2. Verify proxies/load balancers in front are not corrupting chunked bodies
3. Update fasthttp; parsing paths get hardening over time
4. If you call readHexInt-like parsing yourself, pre-check the digit count/value before accumulating

Example fix

// before: trusting an untrusted peer's chunked response
resp, err := client.Get(nil, "http://untrusted-peer/bin")
// after: bound and validate the peer response, or use a checked proxy
client.ReadTimeout = time.Second * 10
resp, err := client.Get(nil, "http://validated-peer/bin")
if err != nil { /* check for malformed chunked peer */ }

// Bound response parsing before trusting a peer
client.ReadTimeout = 10 * time.Second
if resp.Header.Peek(fasthttp.HeaderTransferEncoding) != nil {
    // treat oversized/malformed chunked peers as untrusted
}

if err != nil {
    // errTooLargeHexNum is unexported: match on message
    if strings.Contains(err.Error(), "too large hex number") {
        // mark peer as broken; do not retry the same payload
    }
}

When it happens

Trigger: A peer sends a chunked HTTP body whose chunk-size hex line is enormous (e.g. leading digits that exceed math.MaxInt) so readHexInt's accumulation overflows; also hit when decoding Content-Length-style hex fields via internal helpers.

Common situations: Talking to a buggy or malicious server/proxy that emits invalid chunked encoding; fuzzed or corrupted responses; hand-crafted raw HTTP over a custom connection.

Related errors

• cannot find crlf at the end of chunk
• fasthttp: need more data: cannot find trailing lf
• invalid character '\n' after chunk size
• cannot parse content-length: %w
• empty hex number

AI-assisted analysis of valyala/fasthttp@c96f600972 (2026-08-31). Data as JSON: /api/errors/18542c9c97ec537c. Report an issue: GitHub.