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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
