Hello Oleg,
yes, `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.
Best regards
Dirk
-----Ursprüngliche Nachricht-----
Von: Oleg Kalnichevski <ol...@apache.org>
Gesendet: Mittwoch, 12. August 2020 17:53
An: HttpClient User Discussion <httpclient-users@hc.apache.org>
Betreff: Re: CachingHttpClient fails to revalidate cache entry in case of
chunked transfer encoding
On Wed, 2020-08-12 at 08:35 +0000, Henselin, Dirk (G-GCPS) wrote:
> Hello,
>
> English is not my native language; please excuse typing errors.
> I use HttpClient 4.5.12.
>
> I found that despite a cache hit, the CachingHttpClient returns null,
> if the content-length header was missing in the original response. It
> worked fine after forcing the server to add the content-length header,
> but this isn't possible in case of chunked transfer encoding.
> I looked into the source code and found, that the content-length
> header of a subsequent response is merged into the cache entry's
> response headers, if the content-length header was missing in the
> original response. In case of a 304 content-length=0 is merged into
> the cache entry and this causes returning null instead of the cached
> entity.
> In CachedHttpResponseGenerator I found the following method:
>
> private void addMissingContentLengthHeader(final HttpResponse
> response, final HttpEntity entity) {
> if (transferEncodingIsPresent(response)) {
> return;
> }
> // Some well known proxies respond with Content-Length=0, when
> returning 304. For robustness, always
> // use the cached entity's content length, as modern browsers
> do.
> final Header contentLength = new BasicHeader(HTTP.CONTENT_LEN,
> Long.toString(entity.getContentLength()));
> response.setHeader(contentLength);
> }
>
> Obviously, this method adds a missing content length header, but not
> in case of chunked transfer encoding. How can I solve this?
>
Dirk,
The behavior of this method looks correct to me as `Transfer-Encoding` and
`Content-Length` headers are mutually exclusive.
Could you please provide a reproducer for your original problem?
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
