Search results

I think you need to find some way to improve your php performance, or avoid generate same php page again, using various cache. like page cache, memcache, etc.

How is the custom mime-type set? Can you just change LiteSpeed's global mime configuration?

What text did you put in the note section? does it include any XML specific characters?

Our directory auto index is implemented with PHP, however, the 403 response should not invoke auto index. So, it should be something else. Maybe a PHP powered 403 custom error page.

When DoS feature ban an IP, it will be logged into error.log at "NOTICE" level. something like " ... is over per client soft connection limit ..." or "... Reached per client connection hard limit ..."

Apache is taking the port 443, so it cannot be used by Litespeed. Do you have to have Apache running along LiteSpeed? you should stop Apache and have the whole server powered by LiteSpeed.

Sorry, it only works with Rails app configured this way http://www.litespeedtech.com/support/wiki/doku.php?id=litespeed_wiki:rails_hosting

What kind or error do you get? Is it a error from LiteSpeed? https://www.example.com/ is using port 443 by default.

Apache "SSLRequire" feature is a comprehensive SSL client certificate filtering feature. After some research about revocation, it could be handle by OpenSSL internally, so there should not be big deal to add that as well. We may provide client SSL authentication feature in our 3.3 release soon.

whenever the modified time of that file changes, the rails application will be restarted.

try "touch .ls_restart" under the virtual host root directory.

Those probably are the result of crashed PHP processes. You can remove those files.

turn on debug logging and check error.log for configuration problem. Looks like your script is still configured to run as cgi, if you use LSWS with Apache httpd.conf, make sure "pl" is not configured to run CGI script. just remove related configuration.

Rails app dumps some debug information before sending out the response header I guess.

If the file is located inside a CGI context, it will be executed as CGI script.

The only difference between production and development environment is how RAILS_ENV as populated. So, if it works with production environment but not for development, I think it is a rails internal issue.

We could provide a simple client authentication feature in 3.3 if a feature like "SSLRequire" in Apache mod_ssl is not required. "SSLCARevocationPath" may not be available as well. Basic client authentication is easy to add, but "SSLRequire" and "Revocation" feature are not easy to implement...

You can only view that page from local host, it is how Rails is designed.

We will check and try to find a solution for this problem.

You need to check various log files to find out why. has it been working before?