Hey, I've got a litespeed server (OpenLiteSpeed 1.7.16) serving a Joomla! website (Joomla! 4.1.5) and I've been having an issue with compression. It seems that the compressed files being served by lightspeed are not being uncompressed by the browser (Tested on Mozilla Firefox 103.0 and Chromium 103.0.5060.134), and therefore all the scripts and css files loaded with the website were not working. I've performed a temporary fix by disabling compression on litespeed control panel and deleting all compressed files, and it seems to be working. Of course I'd rather serve compressed files, but I did not figure out what is causing this issue.
Gzip compression breaking website (Joomla)
- Thread starter funni
- Start date
I've tested that the browser is not uncompressing by accessing the page, downloading a css file (which is not human-readable, lots of invalid characters etc), and using gzip to uncompress it. Then it goes from binary to text.
I think the browser is not identifying that the file it is recieving is compressed.
I think the browser is not identifying that the file it is recieving is compressed.
OpenLiteSpeed forum here - https://forum.openlitespeed.org/
are you use LSCache plugin?
are you mean server-side files compression for OLS or content compression?
you can choose what OLS can compress
https://openlitespeed.org/kb/using-gzip-brotli-compression/
are you use LSCache plugin?
are you mean server-side files compression for OLS or content compression?
you can choose what OLS can compress
https://openlitespeed.org/kb/using-gzip-brotli-compression/
I accessed the server through ssh, and just did everything the same way I'd do on my own computer. Wget for downloading files, vim for editing etc. I did not transfer files to the server from my machine.
I am positive this cannot be the case, the problem is clearly not encoding since serving uncompressed files is working. Furthermore, I've tested if the website loads properly in both linux and windows. And If somehow windows uses some type of encoding that linux does not (which I'm confident is not the case) then I'd be out of luck since my own machine does not have windows, and I would not be able to develop my website.
I am positive this cannot be the case, the problem is clearly not encoding since serving uncompressed files is working. Furthermore, I've tested if the website loads properly in both linux and windows. And If somehow windows uses some type of encoding that linux does not (which I'm confident is not the case) then I'd be out of luck since my own machine does not have windows, and I would not be able to develop my website.
Attachments
If that's the case wouldn't issues happen even without compression? And wouldn't it be super common for tons of websites developed in linux to not work on windows and vice-versa? And wouldn't the website load correctly on my machine that is using linux, and incorrectly only on windows? Why none of those things are happening? I don't get it.
The encoding of the files currently is UTF-8, and compressed files are just binary files, and are not encoded. The gzip compression algorithm should work the same no matter the OS. And the normal OLS behaviour should be that it compresses the files and serves the compressed files and it works, if the non-compressed files are working, OLS compressing them and serving them should be working fine, no?
The encoding of the files currently is UTF-8, and compressed files are just binary files, and are not encoded. The gzip compression algorithm should work the same no matter the OS. And the normal OLS behaviour should be that it compresses the files and serves the compressed files and it works, if the non-compressed files are working, OLS compressing them and serving them should be working fine, no?
Last edited:
Anyway, LiteSpeed uses compression for content-encoding that is valid in every browser (gzip,deflate,brotli). LSWS doesn't use a proprietary method. The reason for your issue must be caused on the file system of your OS and the content encoding compression can't handle it. If you would have a local computer you could test it if you upload a text file by FTP and download via browser.
But it is compressing properly, as I've said, downloading the css from the website and uncompressing locally does produce the expected result. I'll send one such file attached and you can try uncompressing it if you want to confirm what I'm saying. https://drive.google.com/file/d/1mlq7MYQXMEUW-YiA5HMJBtsJMOIV7Bbe/view?usp=sharing
Just add .gz to the end of the file and run `gzip -d <filename>` (or whatever you use to decompress gz files).
It cannot be the "file system of my OS" because I've tested on different operating systems (windows 11, Manjaro, and just now Android).
I did not understand the test you're proposing, I already can download uncompressed text files, (html, css, js files are just text files with different extensions). And I also can download compressed text files (css.gz, js.gz), the browser is just not uncompressing them no matter what OS or browser I'm using. My guess is that there is some type of flag or something that indicates to the browser that the file is compressed and it should uncompress it (maybe the file extension itself), and for some reason this flag is not set.
I can already see that my issue probably won't be resolved here, and I'm using OLS which is not what this forum is for. So I'll look for answers elsewhere. Thank you for your time!
Just add .gz to the end of the file and run `gzip -d <filename>` (or whatever you use to decompress gz files).
It cannot be the "file system of my OS" because I've tested on different operating systems (windows 11, Manjaro, and just now Android).
I did not understand the test you're proposing, I already can download uncompressed text files, (html, css, js files are just text files with different extensions). And I also can download compressed text files (css.gz, js.gz), the browser is just not uncompressing them no matter what OS or browser I'm using. My guess is that there is some type of flag or something that indicates to the browser that the file is compressed and it should uncompress it (maybe the file extension itself), and for some reason this flag is not set.
I can already see that my issue probably won't be resolved here, and I'm using OLS which is not what this forum is for. So I'll look for answers elsewhere. Thank you for your time!
main difference between Linux and Windows TEXT file encoding in how CR (Carriage Return), LF (Line Feed) and EOL (End Of Line) coded.
CR - 0x0D, \r
LF - 0x0A, \n
EOL (CR+LF) - 0x0D 0x0A, \r\n
Windows use - \r\n !!!!!!!!!
Linux - \n
and that's why many css and js NOT use anyway CR or LF. when open that files in text editor you can see ONE line.
when you send uncompressed TEXT files then Windows translate Linux \n like LF and execute normally.
when you send compressed TEXT files then Windows decompress and "replace" LF(\n) to EOL(\r\n)
may be "vise versa" but js or css not work.
ways to solve this:
1. use js and css syntax without CR or LF
2. exclude css and js files from compression: !text/css, !text/js
3. disable server-side compression (that you already done)
CR - 0x0D, \r
LF - 0x0A, \n
EOL (CR+LF) - 0x0D 0x0A, \r\n
Windows use - \r\n !!!!!!!!!
Linux - \n
and that's why many css and js NOT use anyway CR or LF. when open that files in text editor you can see ONE line.
when you send uncompressed TEXT files then Windows translate Linux \n like LF and execute normally.
when you send compressed TEXT files then Windows decompress and "replace" LF(\n) to EOL(\r\n)
may be "vise versa" but js or css not work.
ways to solve this:
1. use js and css syntax without CR or LF
2. exclude css and js files from compression: !text/css, !text/js
3. disable server-side compression (that you already done)
Last edited: