Random pages cached incorrectly using VARY

[mkaaaay]

For the most part, vary caching works fine, but then we come across a page that despite containing the same cookies as the other VARY pages, it is showing the NON-VARY cache content.

It's very frustrating because it means we can't cache at all, because logged in users are not seeing the right content. Is this a known bug?

Are we better off changing the htaccess rule to use a cookie that starts with _lscache_vary so LSWS doesn't get confused?

 

[serpent_driver]

Basically, the name of the cookie doesn't matter, so it doesn't have to have _lscache_vary prefix. "Some" say it would get better performance with this prefix.

If you have different cache status with same cache vary, there must be other reason for it, so check you cache rules.

 

[AndreyPopov]

It's very frustrating because it means we can't cache at all, because logged in users are not seeing the right content. Is this a known bug?

it's may be like this https://forum.openlitespeed.org/threads/openlitespeed-v1-7-7-now-available.4719/

[Bug Fix] Update checkCtrlEnv() to enable multiple "vary" values to be added for cache vary cookie.

 

[mkaaaay]

not sure about that bug @AndreyPopov - as that is for the open source version.

Maybe it's a timing thing with my settings? In a nutshell, these are the settings:

phpini:
session.gc_maxlifetime = 86400
session.gc_probability = 1
session.gc_divisor = 1000

codeignitor:
session expiration: 86400

htacess:
<IfModule LiteSpeed>
CacheLookup on
RewriteRule .* - [E=cache-control:max-age=3600]
RewriteCond %{HTTP_COOKIE} _ls_cache_vary_ [NC]
RewriteRule .* - [E=Cache-Control:vary=is_customer]
RewriteRule .* - [E=noconntimeout:1]
RewriteRule .* - [E=noabort:1]
</IfModule>


We have to have a cron running every 20 mins or so to tidy up and clear badly cached pages. I just don't understand why it's not working as it should. For the most part it does, but it's very frustrating.

 

[serpent_driver]

@mkaaaay

I don't exactly understand what your intention is, but

RewriteCond %{HTTP_COOKIE} _ls_cache_vary_ [NC]
RewriteRule .* - [E=Cache-Control:vary=is_customer]

means, that every user that has cookie with prefix _ls_cache_vary_* in cookie name is is_customer. _ls_cache_vary_ is only a prefix and you should name the cookie _ls_cache_vary_cookiename.

 

[serpent_driver]

RewriteRule .* - [E=noconntimeout:1]
RewriteRule .* - [E=noabort:1]

Using both rules without any conditions has a high security risk. Every script has no limits and can't be aborted, so it runs until world goes down or your provider pulls out the power plug of your server. No good idear...

 

[mkaaaay]

@mkaaaay

RewriteCond %{HTTP_COOKIE} _ls_cache_vary_ [NC]
RewriteRule .* - [E=Cache-Control:vary=is_customer]

means, that every user that has cookie with prefix _ls_cache_vary_* in cookie name is is_customer. _ls_cache_vary_ is only a prefix and you should name the cookie _ls_cache_vary_cookiename.

How will changing _ls_cache_vary_cookiename do anything? The cookies are generated by our site, and only this one function has that cookie prefix.

 

[serpent_driver]

Why don't you try it and use the cookie for RewriteCond exactly how it is generated? You already lost and you can only win if you try it. To me, _ls_cache_vary_ is a prefix and needs the cookie name as suffix to complete the cache vary. How long does it take to change RewriteRule? 5 seconds?

In my applications I use up to 30 different cache varies and never had any problems with it!

 

[mkaaaay]

I've made the change and will see what happens. I can't see how it will change as we only have the one cookie with that prefix. Fingers crossed anyway.

 

[serpent_driver]

Thumbs up!

 

[AndreyPopov]

not sure about that bug @AndreyPopov - as that is for the open source version.

if bug existed in open source then if also can exist in others.

this bug corrected in OLS 1.6.18 25th November, but in OLS 1.7.7 only 9th December
may be in LSWS or LSE bug present until now?



for my OLS _lscache_vary cookie is:
_lscache_vary=browser:chrome,os:windows;

for logged user cookie is:
_lscache_vary=session:loggedIn;browser:chrome,os:windows;

for logout user(guest) cookie is:
_lscache_vary=session:loggedOut;browser:chrome,os:windows;

if different language and/or currency then add:
_lscache_vary=session:loggedOut;language:en-gb;currency:usd;browser:chrome,os:windows;

 

[serpent_driver]

if bug existed in open source then if also can exist in others.

Basically yes, but not in this case. This case is completely different. It is not about multiple vary values for cache vary cookie.

 

[AndreyPopov]

Basically yes, but not in this case. This case is completely different. It is not about multiple vary values for cache vary cookie.

I agree that:

RewriteCond %{HTTP_COOKIE} _ls_cache_vary_ [NC]
RewriteRule .* - [E=Cache-Control:vary=is_customer]

wrong way.

but if multiple vary values for cache vary cookie exist and bug present then for cookie:
_lscache_vary=session:loggedOut;language:en-gb;currency:usd;browser:chrome,os:windows;
only first value cached.

and in what order value in _lscache_vary?

may be order like this:
_lscache_vary=language:en-gb;currency:usd;session:loggedIn;browser:chrome,os:windows;
then only language:en-gb cached and session:loggedIn not cached

 

[serpent_driver]

and in what order value in _lscache_vary?

You didn't read what the reported issue is about. There is nothing multiple, neither multiple cookies nor multiple values. The issue with multiple values never exist in LiteSpeed Enterprise.

 

[mkaaaay]

In the end, this seemed to be more of a session issue - session dying but cookie not being destroyed and so pages were caching incorrectly. Hope this helps someone else.

 

[serpent_driver]

In the end, this seemed to be more of a session issue - session dying but cookie not being destroyed and so pages were caching incorrectly. Hope this helps someone else.

Known issue, but that's why it is not good to bind cache vary directly to session cookie.

 

[mkaaaay]

so how else would you do it?

 

[serpent_driver]

so how else would you do it?

There is no 1 for all solution and depends on application. If pages are cached there is no direct way to check if login session still exists, because I need PHP to verify it, so I send an AJAX request that can do that. If there is no session, but login cookie still exists unset this session cookie and everything is okay again.

This is the short way, but depending on application it could be necessary to set an additional cookie and this additional cookie can/should be used to bind cache vary to this cookie and not to the session cookie.

In detail it is little bit more complex, but hope it gives you a kind of direction to solve it.

 

[mkaaaay]

yes, so we do a similar thing also, we use ajax to reload the session every 3 mins, and if found that there is no session, we delete cookies and clear the cache to get rid of any bad caching.

 

[serpent_driver]

Yes, but it is not necessary to check it frequently, if you would use ESI (inline)... .