Search results

Glad to know you have found the issue. We can keep it, in case other users hit the same issue.

Similar to this post. Maybe you can submit a feature request to OpenLiteSpeed GitHub.

This is because the OpenLiteSpeed package relies on certain PHP packages. If you remove something like lsphp83 and its extensions, it could also remove the web server. apt remove lsphp83* ... The following packages will be REMOVED: lsphp83 lsphp83-common lsphp83-imap lsphp83-mysql...

@krlabs, that is expected behavior, to set custom headers with OpenLiteSpeed, please follow https://docs.openlitespeed.org/config/headers/, rewrite header won't work.

FEI, here are the WAF setup, Throttling Setup, and reCAPTCHA Setup guides that could help to mitigate DDoS attacks from the web server side.

Hi, if you think the 520 is a backend server issue, please check the web server error log and see what's in there. FYI, you don't need to whitelist CloudFlare IP again since it's whitelisted by the web server automatically.

Glad to know you have managed to fix the issue. You can also consider setting an empty value or 0 to not limit the PHP process.

I assume you are using app context from the OpenLiteSpeed. Since OpenLiteSpeed comes with Node in detached mode by default, you will need to restart the service to make any new settings take effect. If the app is still under development, maybe you can consider using node to serve the app, and...

It is normal, that if the HTTP port is occupied, then you might be failed to start the OpenLiteSpeed service. You should check why the node service brings up the Nginx on the same server.

FEI, the next release will have it fixed.

Hi @LiteCache, I'm not fully sure I understand the issue you're referring to. Are you saying that the LSCWP built-in crawler is sending an incorrect "vary" header for mobile+webp when crawling the site? Would it be possible for you to open an issue on the LSCWP GitHub so others can follow the...

@rahulsoni should be available now, please confirm.

Thanks for the report, I can reproduce it too, and will forward the issue to the dev. (y)

For LSCache WordPress-related questions, please use the official WordPress support forum to report any issues. Thank you. See you at the LSCache for the WordPress support forum!

Thanks for the report, I will forward it to the team. You can ignore the warning for now since I don't see any update is needed. You might still see the same message after running the `dnf upgrade`.

Hi @rahulsoni lsphp83-redis and lsphp83-imagick for aarch64 should be available, can you give it a try? If lsphp81 is a must, let me know, I will try to fill it up when get a chance.

In my personal opinion, I don't think enabling ZTS helps.

@Akrobs Could you help verify if "mjs = text/javascript" works too?

Sounds great! Perhaps we can include it as the default supported MIME type in a future release.

Glad to know it works!