-
Notifications
You must be signed in to change notification settings - Fork 48
avoid ByteString when parsing HTTP/2 headers #800
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
pjfanning
commented
Sep 26, 2025
- experiment for Http2 header parser can be made more performant #798
- WIP
Breaks 1 Http2ClientSpec test
|
5e2fe91
to
a1ac952
Compare
httpHeaderParser.parseHeaderLine(pekko.util.ByteString(concHeaderLine))() | ||
httpHeaderParser.resultHeader | ||
} else { | ||
HttpHeader.parse(name, value, httpHeaderParser.settings) match { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general that's really cleaner. I don't expect a performance hit, there's a bit of a difference of how the parsers are looked up between HttpHeader.parse
and httpHeaderParser.parseHeaderLine
. HttpHeader.parse
uses binary search to find the right parser and httpHeaderParser.parseHeaderLine
uses kind of a lut / radix lookup once the parser is primed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @jrudolph.
I had to use the startsWith(":")
check because HttpHeader.parse
doesn't support pseudo headers and 1 test includes a :grpc-status
pseudo header.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's annoying
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But wait, does it even parse it into anything useful?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll debug it later. There is an existing test that relies on the header parser not failing. Whether it needs the parser to actually process the pseudo header at all is something that I haven't yet tested.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it's a typo in the test? Is :grpc-status
a thing, i.e. is it allowed for gRPC (outside the HTTP/2 spec) to extend the set of :
pseudo headers?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pekko-grpc also doesn't use the colon form so maybe it's just a typo and we could just fix the test.
Added comments to clarify handling of pseudo-headers in the parseHeaderPair method.
httpHeaderParser.parseHeaderLine(ByteString(concHeaderLine))() | ||
httpHeaderParser.resultHeader | ||
import HttpHeader.ParsingResult | ||
if (name.startsWith(":")) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe just a look ahead char is better