Apache Strict htaccess Option

[Tony]

As it stands currently Litespeed ignores htaccess fatal errors and logic mistakes and continues with execution. This poses a problem for users who expect to be able to interchange between Litespeed and Apache. As this would probably break a lot of installs the only solution I see is an option to have more strict syntax checking that can be turned on. Here are a few examples of scenarios that should break but Litespeed they do not:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^domain\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.domain\.com$
RewriteRule ^/?$ "http\:\/\/www\.domain\.com\/" [R=301,L]

Clear redirection loop but somehow it works on Litespeed.

edirect 301 http://mydomain.com/

Syntax error should be Redirect not edirect but does not produce a 500 error on Litespeed

RewriteCond %{HTTP_USER_AGENT} ^Image Stripper [OR]

In this case it has a space it in Image Stripper it should not. This produces 500's on Apache but on Litespeed parses fine.


These are just a few examples but there are many other syntax errors that work on Litespeed but should be throwing 500's.

 

[mistwang]

LiteSpeed is more fault tolerant than Apache. There are some reasons behind it.

The first case is that LiteSpeed has logic to break the loop redirection, it is feature, not a bug. I do not think that Apache can detects it, have to rely on browsers to detect that.

The second case is that if LiteSpeed start to spit 500 error on unknown directives, it may generate a lot 500 errors than Apache as Litespeed only support a subset of Apache directives. it will cause real trouble than ignoring unknown directives.

The third case is OK to generate 500 error by making LiteSpeed's rewrite engine more strict.

 

[Tony]

LiteSpeed is more fault tolerant than Apache. There are some reasons behind it.

The first case is that LiteSpeed has logic to break the loop redirection, it is feature, not a bug. I do not think that Apache can detects it, have to rely on browsers to detect that.

The second case is that if LiteSpeed start to spit 500 error on unknown directives, it may generate a lot 500 errors than Apache as Litespeed only support a subset of Apache directives. it will cause real trouble than ignoring unknown directives.

The third case is OK to generate 500 error by making LiteSpeed's rewrite engine more strict.

The issue with this approach is we advertise a drop in replacement to Apache. Users then are using our servers to test applications and web sites assuming the same code works in Apache. The missing modules problem would also exist in Apache so I think that is not really the best of arguments. Users should be doing checks for modules if the extensions may not be commonly used.

The problem is code that is so wrong that Apache will throw a 500 error 100% of the time and Litespeed it going through. It creates two problems the first the users assume that code works. The second being it's no longer transferable to Apache.

 

[mistwang]

The "drop-in replacement to Apache" is in the sense that LiteSpeed is compatible with Apache's configuration, but not that LiteSpeed must not take what Apache does not.

You can always validate configuration using Apache's binary at anytime.

To some degree, we will put more effort on detecting bad Apache directives, it is low on our priority as long as it does not break our own product.