Gzip compression breaking website (Joomla)

#1
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.
 

serpent_driver

Well-Known Member
#2
There must be another reason why your CSS and Javascript files seems not to be uncompressed. LiteSpeed doesn't use any compression for content-encoding that isn't unsupported by any browser. What happens if you open the transferred files? Are they readable?
 
#3
There must be another reason why your CSS and Javascript files seems not to be uncompressed. LiteSpeed doesn't use any compression for content-encoding that isn't unsupported by any browser. What happens if you open the transferred files? Are they readable?
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.
 
#5
Is it possible that you use a wrong transfer method for FTP Upload?
I've not used FTP at any point when setting up the server. The server was set up by accessing it through ssh and doing everything directly on it.

I am not very familiar with web stuff, does the browser use FTP to get non html files? I though it was all HTTP.
 
#8
OpenLiteSpeed forum here - https://forum.openlitespeed.org/

are you use LSCache plugin?

are you use files compression for OLS or content compression?

you can choose what OLS can compress
https://openlitespeed.org/kb/using-gzip-brotli-compression/
Oh sorry, I did not know that there were different forums.

I am not using LSCache

All OLS compression settings are the defsult settings, I'm not sure what you are asking though.

I've disabled all compression for now, but ideally I would not have to do so for the page to load correctly.
 
#11
No, but how do you or did you transfer the files to your server?
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.

Maybe this is the reason. If you work directly on linux, files like Javascript or CSS have a different encoding as on Windows.
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

#14
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?
 
Last edited:

serpent_driver

Well-Known Member
#16
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.
 
#17
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!
 

AndreyPopov

Well-Known Member
#19
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.
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)
 
Last edited:
Top