LS Cache randomly breaks page encryption (UTF-8)

S

stevieosaurus

Member
#1
#1
Happens seldomly when LS cache is enabled - page displays in pure gibberish characters, with broken (UTF-8) encryption.
This happens despite specifying at the beginning of each page:

Code: 
<!DOCTYPE html>
<html lang="en-US">
and

Code: 
<meta http-equiv="content-type" content="text/html; charset=utf-8"><meta charset="utf-8">
in the <head> of each page. if I open the same page in a private window it (sometimes) gets fixed all by itself, but not most of the time. Refreshing the same page over and over sometimes fixes it, without doing anything else. Viewing the source code shows that sometimes it’s the entire page encryption is broken, most of the time it's just part of it.
Turning off the "cache" module in the OLS Web Console ALWAYS fixes the page.

OLS version. v1.7.19
OS: Linux Alma x64 v9.4
(I also have Pagespeed module & Security modules enabled, which never affect the bug above mentioned)
 
S

stevieosaurus

Member
#4
#4
UPDATE: disabled pagespeed module, LSCache still (sometimes, randomly) breaks page encryption.
Firefox console error message: "The byte stream was erroneous according to the character encoding that was declared. The character encoding declaration may be incorrect."
(reminder that everything, everywhere is URL-8 specified)
View attachment 1525
View attachment 1525
 
LiteCache

LiteCache

Active Member
#5
#5
@stevieosaurus

The issue is not caused by LScache or by an incorrect encoding format for the output. Especially since the encoding format for the HTML output does not change any bytes. The cause is an incorrect encoding of the source format, which must be either ANSI or UTF-8. Since you are obviously not using a CMS, check the encoding format of the created (php) files.
 
S

stevieosaurus

Member
#6
#6
They are CFC & CFM files (Java Coldfusion), but I get what you meant. That being said, isn't it out of the question that the issue is with the source format, since
  1. MOST OF THE TIME they render correctly.
  2. turning off the LSCache and nothing else ALWAYS fixes the problem.
  3. when the encoding breaks in one browser window, opening another private window (same browser) sometimes renders it correctly. (different cache?)
  4. also tripple-checked everything in the source format, all encoding is UTF-8, not ANSI.
Maybe it's something in my settings?

Code: 
checkPrivateCache   1
checkPublicCache    1
maxCacheObjSize     10000000
maxStaleAge         200
qsCache             1
reqCookieCache      1
respCookieCache     1
ignoreReqCacheCtrl  1
ignoreRespCacheCtrl 0
enableCache         0
expireInSeconds     3600
enablePrivateCache  1
privateExpireInSeconds 3600
LScache.png
 
S

stevieosaurus

Member
#7
#7
A fix would be to be able to check for page encryption errors before displaying the page from cache or disabling/purging cache for said page. Is there any way to do this currently? To check for (cached) page encoding and based on that display it or purge its stored cache version?

Screenshot 2024-07-26 at 07-57-47 LSCache Check - quic.cloud.png
 
LiteCache

LiteCache

Active Member
#8
#8
If you follow the official specifications for generating HTML output, there is no need to fix anything or check anything before caching. Although I don't know of any way to check for correct coding before caching, such a check would make caching unnecessary. You want to get an advantage from caching, but checking beforehand destroys the benefits of caching. Therefore, you can only recommend generating correct HTML output.
 
S

stevieosaurus

Member
#9
#9
LiteCache said:
such a check would make caching unnecessary.
Click to expand...
Makes sense. Still, caching sometimes brakes the UTF-8 page character encryption, and I have no idea how to trace the problem further. HTML output is always correct, proven by the fact that when LScache is disabled, it always displays correctly, the bad encryption instantly disappears.
Any suggestion on how to proceed? What else could it be?
 
LiteCache

LiteCache

Active Member
#10
#10
As already mentioned in a previous post, the cause of your problem arises when the content is generated. Logically, this generated content is not UTF-8. Such problems can arise when content is copied and pasted from other non-Internet compliant sources into a content editor. However, this is only one example of several possible causes. So if you are looking for a solution, you will not find this solution in the web server functions or settings of OLS.
 
AndreyPopov

AndreyPopov

Member
#11
#11
stevieosaurus said:
Any suggestion on how to proceed?
Click to expand...
LSCache stored cached page as HTML static files.
you can find lscache folder and investigate stored HTML static files.

may be some browser(device) that send request with non-UTF8 encoding (ANSI) and after this request lscache HTML static file saved. this saved non-UTF8 HTML static file provided for any requests for this page.
 
LiteCache

LiteCache

Active Member
#12
#12
@AndreyPopov

WOW, you are still alive!

LiteCache said:
The issue is not caused by LScache or by an incorrect encoding format for the output. Especially since the encoding format for the HTML output does not change any bytes. The cause is an incorrect encoding of the source format, which must be either ANSI or UTF-8. Since you are obviously not using a CMS, check the encoding format of the created (php) files.
Click to expand...
 
S

stevieosaurus

Member
#13
#13
Still haven't found a solution to this issue, still encounter it sporadically. Wonder if someone else is facing the same and maybe they found a workaround.

LiteCache said:
your problem arises when the content is generated. Logically, this generated content is not UTF-8.
Click to expand...
The displayed content (directly from LS cache) is indeed NOT UTF-8, which is the problem. The dynamically generated HTML however - requested by OLS from CFML via the Tomcat AJP connector - is indeed UTF-8, every time, since when I turn off LS Cache (+do a graceful OLS restart) upon encountering this issue, it gets fixed every time, thous displaying the non-cached HTML file.
From this I deduce the issue thus must be somewhere between the (already generated) UTF-8 encoded HTML file and how LS cache stores these files, then displays them correctly.

Is it possible LS Cache is so fast in fetching the HTML too soon - before CFM finishes writing it completely - and thous it manages to store it in a partial form, thereby breaking encryption?

AndreyPopov said:
you can find lscache folder and investigate stored HTML static files.
Click to expand...
Pardon my ignorance, but where exactly would I find these cached files? Also, when they are being fetched (via AJP connector), before being cached by OLS, are they stored somewhere on the drive or just in the memory?
 
You must log in or register to reply here.
Top