[MAGNOLIA-2157] cache: wrong content length for resource streamed from docroot Created: 28/May/08  Updated: 23/Jan/13  Resolved: 09/Jun/08

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: 3.6
Fix Version/s: 3.6

Type: Bug Priority: Critical
Reporter: Philipp Bärfuss Assignee: Magnolia International
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relation
is related to MAGNOLIA-2127 New Cache features and api Closed
supersession
supersedes MAGNOLIA-2177 When caching (1st request), we're alw... Closed
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:

 Description   

curl http://localhost:8080/magnoliaPublic/docroot/samples/css/menu.css

--> curl: (18) transfer closed with 442 bytes remaining to read

The connection is kept open for quite a while. You can see the effect quite easily if you open /help.html in a public instance



 Comments   
Comment by Philipp Bracher [ 28/May/08 ]

Note that the magnolia page itself is streamed correctly (91ms)

Comment by Magnolia International [ 04/Jun/08 ]
  • this is probably specific to docroot stuff - to be tested/verified.
Comment by Magnolia International [ 09/Jun/08 ]

this uncovered several issues

  • while the gzip filter sets the content length properly, the container had set it first to the length of the uncompressed document, and it doesn't get overriden. This is the issue described here.
  • if the client does not accept gzip encoding, the cache filter indeed serves the unzipped content, but it still sent the gzip headers in the response.
  • when the cache policy determines the entry needs to be cached, the cache filter always serves the gzipped content even if the client does not accept gzip encoding (even the gzip filter is enabled, of course)
Comment by Magnolia International [ 09/Jun/08 ]

Fixed on svn - see MAGNOLIA-2177 for issue #3

Generated at Mon Feb 12 03:33:58 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.