I observed the following problem: `Transfer-Encoding` and
`Content-Length` headers should be mutually exclusive and because I use
chunked transfer, the `Transfer-Encoding` header is set in the response
while the `Content-Length` header is not. In case of a 304 during a
revalidation, the header contains Content-Length=0. Probably a proxy is
responsible for this, just like the comment "Some well-known proxies
respond with Content-Length=0, when returning 304" in the method
CachedHttpResponseGenerator::addMissingContentLengthHeader is saying. In
CacheEntryUpdater::mergeHeaders the Content-Length=0 is merged into the
cached entry, but the cached entry contains also a `Transfer-Encoding`
header, so in the cached entry these headers aren't mutually exclusive
anymore. Because of the `Transfer-Encoding` header the method
CachedHttpResponseGenerator::addMissingContentLengthHeader isn't fixing
the `Content-Length` header and Content-Length=0 causes returning null
instead of the cached content. IMHO the `Content-Length` header should
not be merged into the cached response in case of a 304, at least if the
cached entry contains a `Transfer-Encoding` header.
SSLConnectionSocketFactory no longer overrides the socket timeout
with the connect timeout when an unlimited socket timeout is
configured. This matches behavior of HTTPCLIENT-2091.
Note that in scenarios where SocketConfig sets an infinite timeout
and the RequestConfig sets a bounded timeout, this change results
in the connect-timeout no longer applying to the TLS handshake.
This behavior can be retained by setting the expected timeout in
the SocketConfig.
Note that this may change the origin of logging when classes
have been subclassed, as the logger origin will use the class
name that defined the logger where previously the subclass type
would be used. In scenarios where external libraries subclass
httpclient utilities this allows httpclient logging to maintain
the `org.apache.hc` prefix instead of inheriting arbitrary
subclass names.
Using some logging frameworks this may result in reduced churn
when httpclient components are created (new connections, for example)
because loggers are looked up once per class.
Both connection managers agree on the meaning of a zero-duration
validateAfterInactivity value. Previously the documentation for
both suggested that zero resulted in no validation, however
the classic client would validate prior to each request and
the async client would never validate.
This commit standardizes behavior on the classic client, which
is consistent with hc4.x, allowing zero to force validation prior
to every request.
Previously HttpClientBuilder methods addExecInterceptorFirst and
addExecInterceptorLast resulted in NullPointerExceptions because
the execInterceptors list had not been initialized yet.
