On Thu, 2020-08-13 at 19:32 +0000, Henselin, Dirk (G-GCPS) wrote: > 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 >
Dirk The original developers of the cache module are no longer with the project. I do not know if there was a rationale for this decision. Please either propose a patch as a PR at GitHub or produce a reproducer I could run locally if you expect me to look into the problem. Oleg > -----Ursprüngliche Nachricht----- > Von: Oleg Kalnichevski <[email protected]> > Gesendet: Mittwoch, 12. August 2020 17:53 > An: HttpClient User Discussion <[email protected]> > 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: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
