[lxcxjxhx]

What

Add a MaxHeaderSize field to HeaderScanner. When set to a positive value, the scanner stops parsing and returns errHeaderTooLong once the cumulative header bytes exceed the limit. The default is 0 (no limit), so existing callers are unaffected.

Why

Malicious or buggy clients can send an arbitrarily large header block and cause the parser to loop until OOM. Having a built-in size guard lets callers defend against this without wrapping the scanner externally.

Changes

• headerscanner.go: add MaxHeaderSize int field and a size check at the top of Next()
• headerscanner_test.go: add TestHeaderScannerMaxHeaderSize and TestHeaderScannerMaxHeaderSizeDisabled

Testing

go test ./pkg/protocol/http1/ext/...

All existing tests pass. New tests cover:

• Headers within limit → parsed normally
• Headers exceeding limit → errHeaderTooLong
• MaxHeaderSize=0 → no limit (backward compatible)

Closes #1497

[CLAassistant]

All committers have signed the CLA.

[lxcxjxhx]

Rebased onto the current main so CI runs on today's toolchain.

The red checks on the previous head were both pkg/common/compress assertions, not this change:

--- FAIL: TestCompressAppendGzipBytesLevel
--- FAIL: TestCompressWriteGzipLevel
FAIL	github.com/cloudwego/hertz/pkg/common/compress

This PR touches pkg/protocol/http1/ext/headerscanner.go and its test; the compress package does not import it, and the failures date from the 2026-08-24 run while main's own Unit Tests have been green since.

Not run locally: this host has no Go toolchain, so the evidence is the rebased diff plus the added headerscanner_test.go cases.