Hi Jan, IMO It’s not a bug, AFAIK. The *protected* constructor is for CDI usage and isn’t intended as the general “default constructor.” Apache HttpClient’s main entry point for creating RequestConfig instances is via RequestConfig.custom(), whose defaults may differ for practical reasons. The CDI constructor simply serves an internal purpose, so any discrepancy in defaults there is generally not considered a bug.
Kind regards Arturo On Fri, Jan 3, 2025 at 10:11 PM jan luehe <janlu...@yahoo.com.invalid> wrote: > The reason I'm asking is because when we upgraded > org.apache.httpcomponents.client5 from version 5.2 to 5.4.1, we ran into > issues where the client request was rejected by the server due to an > invalid header combination: > Upgrade: TLS/1.2Connection: keep-alive > This header combination is invalid because if the "Upgrade" header is > present, the "Connection" header must equal to, or contain the string > "Upgrade". > Since we are going through RequestConfig$Builder, "protocolUpgradeEnabled" > was automatically enabled, and we had to set it to "false" in order to > disable it. > > On Friday, January 3, 2025 at 10:12:37 AM PST, jan luehe < > janlu...@yahoo.com> wrote: > > Support for org.apache.hc.client5.http.config.RequestConfig's > "protocolUpgradeEnabled" was introduced via this commit: > https://github.com/apache/httpcomponents-client/commit/3235f009d5673536be5c668df409ac3f83808d89 > The default RequestConfig constructor sets it to "false", whereas the > RequestConfig$Builder sets it to "true" by default. > Same is true for RequestConfig's "contentCompressionEnabled" and > "hardCancellationEnabled" fields. > I believe RequestConfig$Builder should initialize these fields to "false" > also.
