Search results

website has been fixed, please try 5.x.

Yes. not possible.

How is the vhost configured? through Apache httpd.conf? control panel? is radschool.or.au one of the vhost hosted in that server? If you are using 5.0.1 release, you should force update the latest build. /usr/local/lsws/admin/misc/lsup.sh -f -v 5.0.1

Can You locate "FormMail.pl" in your server? Just copy it to the location mentioned in the error message.

as long as those domains pointing to that IP, open port 443 on that IP will open https for all domains. Nobody can prevent that unless you pointing only one domain to that IP, in the other words, that IP is owned by that domain only. Server will use SNI to determine which SSL certificate will...

Maybe PHP engine itself is doing compression, turn it off and let litespeed handle the compression.

That's even better! :-)

cxs run as an external process, it can only see real environment variable. PHP's $ENV[] array is not real process environment, but a virtual one only known for PHP internal. Only when PHP was running as CGI, all request info are passed as real process environment, so I suspect that cxs only...

If your server's I/O wait is high, it could slow down LiteSpeed main server process. Then need to do some thing to minimize the impact of high I/O wait. You should setup a monitoring script from localhost or in the same LAN. A long delay could be a network issue as well.

This bug is fixed, your server has been upgraded to 5.0.1 pre-release package.

Let us know how you disable the rule? And you need to confirm that the way you did works with Apache, something, it is just a configuration problem. If it works with Apache, we will make it work properly with LiteSpeed.

We will take a look.

you can contact bug@litespeed... as well.

it is due to the new version of PHP engine, not the new version of lsapi. the change is minimum, just API call change to match the engine changes.

you can do exact same with LiteSpeed.

If it happens again, please check request cookie headers. It could be a bug in handling the cookie header during HTTP/2 header compression. We need to figure it out.

You just need those rules added to configuration in someway, do not have to have full installation, as long as you can get those rules.

If it is easy for your partner to reproduce this problem. you can turn on full debug logging for a short while, let your partner to reproduce the problem. We will locate related log entries by using his IP. For chrome, the HTTP/2 and SPDY indicator should be installed. click the indicator, you...

50 is too small, we cannot limit bandwidth to 50 bytes/second. try a large number, 50000 maybe.

We need to check the server if the resource usage of lshttpd keep growing.