[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: |
|
||||
| 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:
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. |
| 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. 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. |