-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Allows configuring the initial HTTP/2 settings #33777
Allows configuring the initial HTTP/2 settings #33777
Conversation
🙈 The PR is closed and the preview is expired. |
This comment has been minimized.
This comment has been minimized.
The Maven test failures seem suspicious... |
02c09bc
to
1a0bdae
Compare
@geoand yes and no, they got fixed in another PR about the double Kubernetes service ports. I just based my PR on a broken version. I've rebased, so, it should be fine. |
👌 |
Failing Jobs - Building 1a0bdae
Full information is available in the Build summary check run. Failures⚙️ Native Tests - Amazon #- Failing: integration-tests/amazon-lambda-http
📦 integration-tests/amazon-lambda-http✖
|
/** | ||
* Set the SETTINGS_HEADER_TABLE_SIZE HTTP/2 setting. | ||
* <p> | ||
* Allows the sender to inform the remote endpoint of the maximum size of the header compression table used to decode | ||
* header blocks, in octets. The encoder can select any size equal to or less than this value by using signaling | ||
* specific to the header compression format inside a header block. | ||
* The initial value is {@code 4,096} octets. | ||
*/ | ||
@ConfigItem | ||
public OptionalLong headerTableSize; | ||
|
||
/** | ||
* Set SETTINGS_MAX_CONCURRENT_STREAMS HTTP/2 setting. | ||
* <p> | ||
* Indicates the maximum number of concurrent streams that the sender will allow. This limit is directional: it | ||
* applies to the number of streams that the sender permits the receiver to create. Initially, there is no limit to | ||
* this value. It is recommended that this value be no smaller than 100, to not unnecessarily limit parallelism. | ||
*/ | ||
@ConfigItem | ||
public OptionalLong maxConcurrentStreams; | ||
|
||
/** | ||
* Set the SETTINGS_MAX_FRAME_SIZE HTTP/2 setting. | ||
* Indicates the size of the largest frame payload that the sender is willing to receive, in octets. | ||
* The initial value is {@code 2^14} (16,384) octets. | ||
*/ | ||
@ConfigItem | ||
public OptionalInt maxFrameSize; | ||
|
||
/** | ||
* Set the SETTINGS_MAX_HEADER_LIST_SIZE HTTP/2 setting. | ||
* This advisory setting informs a peer of the maximum size of header list that the sender is prepared to accept, | ||
* in octets. The value is based on the uncompressed size of header fields, including the length of the name and | ||
* value in octets plus an overhead of 32 octets for each header field. | ||
* The default value is {@code 8192} | ||
*/ | ||
@ConfigItem | ||
public OptionalLong maxHeaderListSize; |
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.
Just a thought: Should these be under a dedicated http2
group?
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 was wondering the same, but because these are limits, it's a bit weird to have them separately like:
- quarkus.http.limits for http/1 and http/1.1
- quarkus.http.http2 for http/2
But I don't have a strong opinion.
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 I don't have a strong opinion.
Me neither, so let's just leave it as is
Fix #33692