README: size the .NET binding field arrays to the limits (overflow-safe)#42
Merged
Conversation
The example sized headers/query at 64/32 but Glyph11Limits.Default allows 100/128, so the arrays filled before the limit and wrongly 431'd requests within policy (the core bounds-checks every write — line 495 — so it's safe, just a lowered effective limit). Size storage from the limits (MaxHeaderCount / MaxQueryParameterCount) and note ArrayPool for large limits. Verified: an 80-header request parses with a 100-array (status 0, 80 headers) and is rejected with a 64-array (status 304 = TOO_MANY_HEADERS -> 431), no overflow. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Benchmark
Details
| Benchmark suite | Current: 7c0e4ed | Previous: d3a06f0 | Ratio |
|---|---|---|---|
Benchmarks.FlexibleParserBenchmark.Small_ROM |
139.85827469825745 ns (± 1.7895346768317675) |
139.20921897888184 ns (± 0.3414138670448296) |
1.00 |
Benchmarks.FlexibleParserBenchmark.Small_MultiSegment |
354.2074731190999 ns (± 2.1668833462062906) |
349.4604838689168 ns (± 2.860363450836272) |
1.01 |
Benchmarks.FlexibleParserBenchmark.Header4K_ROM |
709.1790765126547 ns (± 2.051860914954907) |
708.5051829020182 ns (± 2.487052061932313) |
1.00 |
Benchmarks.FlexibleParserBenchmark.Header4K_MultiSegment |
1835.8866113026936 ns (± 13.099643260069303) |
1826.123291015625 ns (± 16.460001723138515) |
1.01 |
Benchmarks.FlexibleParserBenchmark.Header32K_ROM |
5199.487007141113 ns (± 9.028263316211827) |
4949.9634958903 ns (± 10.64757006352856) |
1.05 |
Benchmarks.FlexibleParserBenchmark.Header32K_MultiSegment |
12585.95969136556 ns (± 43.544452781019125) |
12010.515991210938 ns (± 66.48393176840845) |
1.05 |
Benchmarks.UltraHardenedParserBenchmark.Small_ROM |
251.4251831372579 ns (± 0.17476117914061998) |
252.88829962412515 ns (± 1.7230360417772392) |
0.99 |
Benchmarks.UltraHardenedParserBenchmark.Small_MultiSegment |
503.6839647293091 ns (± 5.548179415543569) |
559.2204907735189 ns (± 4.167496342803848) |
0.90 |
Benchmarks.UltraHardenedParserBenchmark.Header4K_ROM |
1106.6140003204346 ns (± 1.109570237213264) |
1118.6354840596516 ns (± 0.7807947528732518) |
0.99 |
Benchmarks.UltraHardenedParserBenchmark.Header4K_MultiSegment |
2560.8383509318032 ns (± 41.698543168398835) |
2225.3782081604004 ns (± 17.533121532742204) |
1.15 |
Benchmarks.UltraHardenedParserBenchmark.Header32K_ROM |
7805.213531494141 ns (± 39.95851376311932) |
7139.710075378418 ns (± 18.12358659190381) |
1.09 |
Benchmarks.UltraHardenedParserBenchmark.Header32K_MultiSegment |
16478.852864583332 ns (± 149.39766746605645) |
15398.131754557291 ns (± 158.60331507605568) |
1.07 |
Benchmarks.FlexibleParserBenchmark.Small_ROM.Allocated |
0 ns (± 0) |
0 ns (± 0) |
1 |
Benchmarks.FlexibleParserBenchmark.Small_MultiSegment.Allocated |
112 ns (± 0) |
112 ns (± 0) |
1 |
Benchmarks.FlexibleParserBenchmark.Header4K_ROM.Allocated |
0 ns (± 0) |
0 ns (± 0) |
1 |
Benchmarks.FlexibleParserBenchmark.Header4K_MultiSegment.Allocated |
4128 ns (± 0) |
4128 ns (± 0) |
1 |
Benchmarks.FlexibleParserBenchmark.Header32K_ROM.Allocated |
0 ns (± 0) |
0 ns (± 0) |
1 |
Benchmarks.FlexibleParserBenchmark.Header32K_MultiSegment.Allocated |
32800 ns (± 0) |
32800 ns (± 0) |
1 |
Benchmarks.UltraHardenedParserBenchmark.Small_ROM.Allocated |
0 ns (± 0) |
0 ns (± 0) |
1 |
Benchmarks.UltraHardenedParserBenchmark.Small_MultiSegment.Allocated |
128 ns (± 0) |
128 ns (± 0) |
1 |
Benchmarks.UltraHardenedParserBenchmark.Header4K_ROM.Allocated |
0 ns (± 0) |
0 ns (± 0) |
1 |
Benchmarks.UltraHardenedParserBenchmark.Header4K_MultiSegment.Allocated |
4128 ns (± 0) |
4128 ns (± 0) |
1 |
Benchmarks.UltraHardenedParserBenchmark.Header32K_ROM.Allocated |
0 ns (± 0) |
0 ns (± 0) |
1 |
Benchmarks.UltraHardenedParserBenchmark.Header32K_MultiSegment.Allocated |
32800 ns (± 0) |
32800 ns (± 0) |
1 |
This comment was automatically generated by workflow using github-action-benchmark.
Contributor
There was a problem hiding this comment.
⚠️ Performance Alert ⚠️
Possible performance regression was detected for benchmark.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.15.
| Benchmark suite | Current: 7c0e4ed | Previous: d3a06f0 | Ratio |
|---|---|---|---|
Benchmarks.UltraHardenedParserBenchmark.Header4K_MultiSegment |
2560.8383509318032 ns (± 41.698543168398835) |
2225.3782081604004 ns (± 17.533121532742204) |
1.15 |
This comment was automatically generated by workflow using github-action-benchmark.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The example sized headers/query at 64/32 but Glyph11Limits.Default allows 100/128, so the arrays filled before the limit and wrongly 431'd requests within policy (the core bounds-checks every write — line 495 — so it's safe, just a lowered effective limit). Size storage from the limits (MaxHeaderCount / MaxQueryParameterCount) and note ArrayPool for large limits. Verified: an 80-header request parses with a 100-array (status 0, 80 headers) and is rejected with a 64-array (status 304 = TOO_MANY_HEADERS -> 431), no overflow.