Litespeed returns 403 when rewriting the URL of an existing image-CodePudding

My customer is using Litespeed with CPanel v106.0.10. I have a RewriteRule like this in .htaccess file:

RewriteCond %{HTTP_HOST} ^www.site.com$
RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond %{DOCUMENT_ROOT}%{ENV:REWRITEBASE}/img/$1.webp -s
RewriteRule ^img/([_a-zA-Z0-9-] )\.jpg$ %{ENV:REWRITEBASE}img/$1.webp [B,L]
RewriteCond %{HTTP_HOST} ^www.site.com$
RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond %{DOCUMENT_ROOT}%{ENV:REWRITEBASE}/img/$1.webp !-s
RewriteRule ^img/([_a-zA-Z0-9-] )\.jpg$ %{ENV:REWRITEBASE}webp.php?src=img/$1.jpg [B,L]

The goal is to serve images into WEBP format when the WEBP file exists, if not then call the PHP script to compress the JPG file into WEBP format. It's working good with Apache but when using Litespeed server I get a 403 error when the WEBP file does not exists. Also when the URL of the image does not match the real file name (URL rewriting) then it also works. So I think there is something that blocks URL rewriting when the URL match with a real file. Who can help?

CodePudding user response：

I found that this is a difference between Apache and Litespeed.

Litespeed does not prioritize the rules defined in .htaccess files in the same way as Apache. Thus PHP files are forbidden in the "/img" directory, when the URL "/img/image.webp" arrives, Apache applies the redirection to the PHP compressor but does not apply the "access denied" on the script because it is not in the "/img" directory, whereas Litespeed applies the redirection to the PHP compressor but blocks access to it (403) because the original URL starts with "/img".

I guess that this is a bug from Litespeed.