What causes "doesnot support length bigger than int32 max " in AlistGo/alist?

Clamp or validate length before calling: ensure 0 <= length <= math.MaxInt.

doesnot support length bigger than int32 max

Error message

doesnot support length bigger than int32 max

What it means

GetRangedHttpReader rejects length values that cannot be represented as an int on the target platform (checked against math.MaxInt; message says int32 max though it means platform int). Because the fallback path reads the WHOLE body and discards offset bytes, a huge length would imply buffering an enormous slice, so it refuses up front.

Source

Thrown at internal/net/util.go:338

		buf = buf[0:l.remaining]
	}

	n, err := l.rc.Read(buf)
	l.remaining -= n

	return n, err
}

func (l *LimitedReadCloser) Close() error {
	return l.rc.Close()
}

// GetRangedHttpReader some http server doesn't support "Range" header,
// so this function read readCloser with whole data, skip offset, then return ReaderCloser.
func GetRangedHttpReader(readCloser io.ReadCloser, offset, length int64) (io.ReadCloser, error) {
	var length_int int
	if length > math.MaxInt {
		return nil, fmt.Errorf("doesnot support length bigger than int32 max ")
	}
	length_int = int(length)

	if offset > 100*1024*1024 {
		log.Warnf("offset is more than 100MB, if loading data from internet, high-latency and wasting of bandwidth is expected")
	}

	if _, err := utils.CopyWithBuffer(io.Discard, io.LimitReader(readCloser, offset)); err != nil {
		return nil, err
	}

	// return an io.ReadCloser that is limited to `length` bytes.
	return &LimitedReadCloser{readCloser, length_int}, nil
}

View on GitHub (pinned to 843d9dc814)

Solutions

Clamp or validate length before calling: ensure 0 <= length <= math.MaxInt.
On 32-bit platforms, split the transfer into multiple smaller reads.
Prefer a server/path that supports Range headers so the discard-based fallback is not used.
Fix the caller passing an unvalidated int64 (e.g. contentLength) straight through.

Example fix

// before
reader, err := GetRangedHttpReader(res.Body, offset, contentLength) // contentLength int64

// after
length := contentLength
if length > int64(math.MaxInt) {
    length = int64(math.MaxInt)
}
reader, err := GetRangedHttpReader(res.Body, offset, length)

Defensive patterns

Strategy: validation

Validate before calling

const maxLen = int64(math.MaxInt)
if length < 0 || length > maxLen {
    length = maxLen // or split the transfer into segments
}

Type guard

strings.Contains(err.Error(), "doesnot support length")

Try / catch

rc, err := GetRangedHttpReader(body, offset, length)
if err != nil {
    if strings.Contains(err.Error(), "doesnot support length") {
        // split into <= MaxInt segments and loop
    }
}

Prevention

Validate int64 lengths against math.MaxInt before calling on 32-bit targets.
Prefer Range-capable servers so the whole-body-discard fallback is never used.
Avoid passing sentinel values like -1 as length; normalize them first.

When it happens

Trigger: Calling GetRangedHttpReader with a length exceeding math.MaxInt (e.g. int64 value from a Content-Length or range calc passed on a 32-bit build), typically for a very large or unknown size encoded as a big int64.

Common situations: 32-bit builds (linux/386, windows/386, arm) downloading multi-GB files through servers without Range support; callers computing length as file size or remaining bytes; size passed as -1 sentinel interpreted as huge.

Related errors

AI-assisted analysis of AlistGo/alist@843d9dc814 (2026-08-15). Data as JSON: /api/errors/86b0d6fa5fa1ad56. Report an issue: GitHub.