[MGNLCACHE-196] Incorrect value in Content-Length header value Created: 23/Jan/18  Updated: 09/Jul/18  Resolved: 06/Jul/18

Status: Closed
Project: Cache Modules
Component/s: browser cache, gzip
Affects Version/s: 5.5.6, 5.6, 5.6.1
Fix Version/s: 5.5.8, 5.6.2

Type: Bug Priority: Neutral
Reporter: Jonas Furrer Assignee: Michael Mühlebach
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

CentOS


Issue Links:
relation
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Epic Link: Support
Sprint: Kromeriz 136, Basel 150
Story Points: 8

 Description   

With the following preconditions, the Content-Length header is incorrect:

  • Request to a Spring-Controller over an additional Blossom dispatcher servlet (configured as described in the Blossom documentation)
  • Request is cached by the Magnolia cache module
  • Gzip is enabled for this request

The issue seems to be in the method info.magnolia.module.cache.filter.InMemoryCachedEntry#writeContent. The Spring-Controller adds the Content-Length header with the value of the uncompressed length to the HTTPServletResponse. The writeContent method in InMemoryCachedEntry.java sets the correct Content-Length value to the HTTPServletResponse but not to the Header-MultiMap used with the response wrapper and delivered to the browser.

You can see an incorrect Header value in a browser.



 Comments   
Comment by Jonas Furrer [ 20/Feb/18 ]

The behaviour is dependent on the configuration of the webserver infrastructure, but basically, if the Content-Length header is not correct, the browser tries to keep the connection open, until as many data is delivered as the Content-Length header states.
Since the data is delivered with GZIP compression and the Content-Length header contains the size of the not compressed data, the connection wont close.
If the webserver has keep-alive enabled, the browser keeps loading until the keep-alive timeout is reached, then the browser displays an error. If keep-alive is disabled the behaviour might differ.

Comment by Michael Mühlebach [ 02/Jul/18 ]

It think I found the issue and a possible solution. The (Gzip)CacheResponseWrapper is not replaying all headers correctly to the actual response and has already specific implementations for Content-Type and Character-Encoding. It looks to me like we have correct response wrapper but do not use its headers for all attributes for whatever reasons. So the solution is simple: treat Content-Length special as well. As this is not specific to blossom I think we might have this issue in general.
Thats not a sustainable solution and we should refactor that area of code for a next major release

Anyway, it looks like for a maintenance release the solution is rather quick and small. But as the whole gzip, cache, blossom area is rather complex, it would be quite benefitial if jfurrer could use a snapshot version of cache to validate the fix in their setup.
evystup^

Generated at Sun Feb 11 23:53:08 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.