CoreCommunity ExtensionsIncubatorDistributionsTYPO3 4.5 ProjectsTYPO3 4.6 ProjectsTYPO3 4.7 ProjectsTYPO3 6.0 ProjectsTYPO3 6.1 ProjectsTYPO3 6.2 Projects (+)

Bug #31815

wrong Content-Length header if gzip encoding is enabled

Added by Andreas over 1 year ago. Updated 9 months ago.

Status:Needs Feedback Start date:2011-11-15
Priority:Should have Due date:
Assignee:- % Done:

0%

Category:-
Target version:-
Votes: 0

Description

Hi,

if a client sends "Accept-Encoding: gzip, deflate" the calculated Content-Lenght is wrong which causes corrupted downloads (e.g. zip file which cannot be opened or content is corrupt after extracting).

I've fixed it by commenting out the "header('Content-Length: ' . $this->intFileSize);" in "class.tx_nawsecuredl_output.php" line 151.
A drawback is that browser's download status bar does not show the file size and estimated download time, size.
This is not nice, but better than having corrupted downloads.

There are some hints at stackoverflow, e.g. http://stackoverflow.com/questions/815961/how-to-determine-the-content-length-of-a-gzipped-file, but unfortinately I was not able to get it working including the suggested changes.

Does anyone know how to fix this correctly?

Kind regards
Andreas

History

Updated by Helmut Hummel 9 months ago

  • Status changed from New to Needs Feedback

Do you have $TYPO3_CONF_VARS['FE']['compressionLevel'] enabled in your TYPO3 installation?

Or did you configure Apache to do the compression

Just the client headers would do nothing.

Also available in: Atom PDF