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.
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.
MemcachedCacheEntryHttp inner class NoAgeCacheValidityPolicy should be static.
Add missing javadoc @param and @return entries to MemcachedCacheEntryHttp.
Remove extra blank lines.
Modeled after StandardCharsets, the new class indicates a non-exhaustive
list of standard auth schemes by name supported by the HttpClient. The
previous enum suffered from two issues:
* it was exhaustive implying that no more auth schemes can be supported
* its sole purpose was to contain an id for the declared auth scheme;
the enum values theirselves were never used directly
This closes#196