Go version
go1.25.7
What did you do?
The addition of FramePriorityUpdate (0x10) in the RFC 9218 implementation (go.dev/issue/75500) introduced a gap in the frameParsers array. The array now has 17 elements (indices 0-16), but indices 10 through 15 are nil because no parser is assigned for those frame types.
typeFrameParser does not check for nil before returning:
var frameParsers = [...]frameParser{
FrameData: parseDataFrame, // 0
...
FrameContinuation: parseContinuationFrame, // 9
// indices 10-15 are nil
FramePriorityUpdate: parsePriorityUpdateFrame, // 16
}
func typeFrameParser(t FrameType) frameParser {
if int(t) < len(frameParsers) {
return frameParsers[t] // returns nil for t=10-15
}
return parseUnknownFrame
}The returned parser is immediately invoked in ReadFrame / ReadFrameForHeader:
f, err := typeFrameParser(fh.Type)(fr.frameCache, fh, fr.countError, payload)
Before this change, the array had 10 elements (indices 0-9), so any frame type >= 10 correctly fell through to parseUnknownFrame.
What did you expect to see?
Frame types 0x0a through 0x0f should be handled as unknown frames via parseUnknownFrame, consistent with all other unregistered frame types.
What did you see instead?
Receiving an HTTP/2 frame with type 0x0a-0x0f causes a nil function call panic. Frame type 0x0a is ALTSVC (RFC 7838) and 0x0c is ORIGIN (RFC 8336), both of which are IANA-registered HTTP/2 frame types that may be sent by peers in practice.
A possible fix:
func typeFrameParser(t FrameType) frameParser {
if int(t) < len(frameParsers) {
if f := frameParsers[t]; f != nil {
return f
}
}
return parseUnknownFrame
}
Go version
go1.25.7
What did you do?
The addition of
FramePriorityUpdate(0x10) in the RFC 9218 implementation (go.dev/issue/75500) introduced a gap in theframeParsersarray. The array now has 17 elements (indices 0-16), but indices 10 through 15 are nil because no parser is assigned for those frame types.typeFrameParserdoes not check for nil before returning:The returned parser is immediately invoked in
ReadFrame/ReadFrameForHeader:Before this change, the array had 10 elements (indices 0-9), so any frame type >= 10 correctly fell through to
parseUnknownFrame.What did you expect to see?
Frame types 0x0a through 0x0f should be handled as unknown frames via
parseUnknownFrame, consistent with all other unregistered frame types.What did you see instead?
Receiving an HTTP/2 frame with type 0x0a-0x0f causes a nil function call panic. Frame type 0x0a is ALTSVC (RFC 7838) and 0x0c is ORIGIN (RFC 8336), both of which are IANA-registered HTTP/2 frame types that may be sent by peers in practice.
A possible fix: