Re: [tomcat] branch 9.0.x updated: Fix BZ 66455 - avoid ClassCastException when processing window update

[Christopher Schultz <ch...@christopherschultz.net>]

Mark,

On 1/30/23 18:08, Mark Thomas wrote:
> On 30/01/2023 21:03, Christopher Schultz wrote:
> 
> <snip/>
> 
>> Is the default window size really 65535 bytes (64k - 1)? That would be 
>> very unusual (is this some kind of spec-mandated window size? still 
>> seems weird). It seems more likely that it is a full 64k bytes and 
>> that the max index into that array would be 64k - 1.
> 
> RFC 9113, section 6.5.2, SETTINGS_INITIAL_WINDOW_SIZE
> 
> "The initial value is (2^16)-1 (65,535) octets."
> 
> 
>> How does sending a window update of 1025 increase the connection 
>> window size to 57k? Why won't 1024 do it? Or 512? Or 1024 * 57? Or (64 
>> - 8) * 1024 - 1?
> 
> Initial size: 64k -1
> Initial request (sent as part of http2Connect()) has an exactly 8k 
> response body.
> New size = 64k - 1 - 8k
>           = 56k -1
> 
> Increase window size by 1k +1 gives:
> 56k - 1 + 1k + 1 = 57k
> 
>> How does sending 7 updates with odd i values between 3 and 17 fill the 
>> first 56k of the connection window?
> 
> 7 requests each with response bodies of 8k uses 7 * 8k = 56k of the 
> connection window.
> 
>> Why use 3 - 17 instead of 0 - 6? Or, if you need some single-digit i 
>> values and some double-digits, why not use more straightforward loop 
>> bounds. It just looks very strange with no explanation.
> 
> RFC 9113, section 5.1.1
> 
> "Streams initiated by a client MUST use odd-numbered stream identifiers; 
> those initiated by the server MUST use even-numbered stream identifiers. 
> A stream identifier of zero (0x00) is used for connection control 
> messages; the stream identifier of zero cannot be used to establish a 
> new stream.
> 
> The identifier of a newly established stream MUST be numerically greater 
> than all streams that the initiating endpoint has opened or reserved."
> 
> The initial request was stream 1. Hence the next 7 requests are streams 
> 3, 5, 7, 9, 11, 13 and 15.
> 
>> I hope these questions aren't just annoying. I'm sure you know what 
>> you are doing. But I know if I was looking at this code to figure out 
>> why the unit test was failing in the future, I would be at a serious 
>> loss to understand what it was even doing in the first place.
> 
> Yes, trying to do that without first understanding the HTTP/2 protocol 
> would be tricky.

Thanks for taking the time to explain. :)

-chris

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org