[jboss-jira] [JBoss JIRA] (WFLY-7692) http2-* attributes def values in Undertow for listeners and mod-cluster

[Chao Wang (JIRA)]

     [ https://issues.jboss.org/browse/WFLY-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chao Wang updated WFLY-7692:
----------------------------
    Git Pull Request: https://github.com/wildfly/wildfly/pull/9430, https://github.com/wildfly/wildfly/pull/9829  (was: https://github.com/wildfly/wildfly/pull/9430)


> http2-* attributes def values in Undertow for listeners and mod-cluster
> -----------------------------------------------------------------------
>
>                 Key: WFLY-7692
>                 URL: https://issues.jboss.org/browse/WFLY-7692
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.1.0.Final
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>            Priority: Minor
>             Fix For: 11.0.0.Alpha1
>
>
> For {{http-listener}}, {{https-listener}} and {{mod-cluster}} filter in Undertow subsystem, there are some http2 related attributes:
> {code}
>             "http2-header-table-size" => {
>                 "type" => INT,
>                 "description" => "The size of the header table used for HPACK compression, in bytes. This amount of memory will be allocated per connection for compression. Larger values use more memory but may give better compression.",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "unit" => "BYTES",
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "all-services"
>             },
>             "http2-initial-window-size" => {
>                 "type" => INT,
>                 "description" => "The flow control window size that controls how quickly the client can send data to the server",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "unit" => "BYTES",
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "all-services"
>             },
>             "http2-max-concurrent-streams" => {
>                 "type" => INT,
>                 "description" => "The maximum number of HTTP/2 streams that can be active at any time on a single connection",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "all-services"
>             },
>             "http2-max-frame-size" => {
>                 "type" => INT,
>                 "description" => "The max HTTP/2 frame size",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "unit" => "BYTES",
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "all-services"
>             },
>             "http2-max-header-list-size" => {
>                 "type" => INT,
>                 "description" => "The maximum size of request headers the server is prepared to accept",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "unit" => "BYTES",
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "all-services"
>             },
> {code}
> By default, all of these attributes are set as undefined. This might be reasonable e.g. for {{http2-max-concurrent-streams}} which in that case might mean that actual maximal value is not restricted anyhow (is it actually true?). But for other attributes this might be misleading for user as he actually does not know what is real default and used value (e.g. for {{http2-initial-window-size}} is used 65535) in such situation. Thus I think that we should provide some default values here so user knows what values are used.
> EDIT: also please pay some attention to a {{max-ajp-packet-size}} attribute that is available in {{ajp-listener}} and {{mod-cluster}} filter - there is no default value set here (undefined by default although I believe some default is actually used - 8192?) and also no units are specified in resource-description for that one (bytes, I believe, should that be).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)