Uh oh!
There was an error while loading. Please reload this page.
Respect SETTINGS_MAX_HEADER_LIST_SIZE on HTTP/2 and HTTP/3 - #79281
Conversation
ghost
commented
Dec 6, 2022
Tagging subscribers to this area: @dotnet/ncl Issue DetailsCloses #78193 This PR does approximate header list length calculations for HTTP/2 and HTTP/3 in order to enforce the Do we care about the calculated length being exactly correct? Given this limit is generally really high and should only be hit in exceptional cases, I don't think we do. Doing precise bookkeeping would mainly represent a maintenance burden for us (and a slight performance overhead). The current approach of taking the encoded length from HPACK works well as long as we don't support the dynamic table/compression for request headers. cc: @Tratcher
|
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
MihaZupan
commented
Dec 13, 2022
@Tratcher can you please take a look at this one if this reduced change still makes sense to you? |
Uh oh!
There was an error while loading. Please reload this page.
7efb4f5 to
d8d975aCompareMihaZupan
commented
Dec 27, 2022
/backport to release/7.0 |
Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3787989385 |
Closes#78193
This PR does approximate header list length calculations for HTTP/2 and HTTP/3 in order to enforce the
SETTINGS_MAX_HEADER_LIST_SIZEsetting. It is a slight overestimation of the actual size (mainly from counting the overhead of HPACK framing), therefore making the client slightly more strict than the spec describes.ASP.NET Core on the other hand is slightly less strict than the spec describes dotnet/aspnetcore#44668 (this is good, you don't want the client/server to be the other way around).
Do we care about the calculated length being exactly correct? Given this limit is generally really high and should only be hit in exceptional cases, I don't think we do. Doing precise bookkeeping would mainly represent a maintenance burden for us (and a slight performance overhead). The current approach of taking the encoded length from HPACK works well as long as we don't support the dynamic table/compression for request headers.
cc: @Tratcher