Search results

That error means that the backend does not send back a valid HTTP response header. It might be a result of previous canceled request and the connection has not been closed for some reason, and previous request has been buffered? We will investigate. However, this message won't affect anything...

can you please PM me a temp root access? I can take a look.

Thanks! Updated 3.3.5 release package has been uploaded. everything should be working as expected. you can download and give it try. Just change the version number in the download link.

4) has been identified and fixed.

3) when a request was blocked, something like following should be in error.log

1) and 2) are related, and the bug has been identified and fixed.

Thank you for the detail bug report. I am checking it. What kind of rule do you use for checking cookies? If you think anything does not work as expected, just give an example rule and request for us to reproduce it.

updated 3.3.5 release package has been uploaded, you need to upgrade to it manually. Just change the version number in the download link to get it. It should fix the performance issue with frontpage. A new configuration option has been added in the Apache configuration section, to explicitly...

The configuration will applied to all vhosts when you set "ErrorDocument" directive, just that not all vhost has the 404.html in their document root. If available, the custom page will be used.

You need to get the Enterprise edition, Our server is a Apache replacement server, most Apache features are support and the implementation is much better than Apache's. Our caching module will be released soon. I am not sure how much you rely on this. I would recommend you to apply a free trial...

We will release 3.3.5 update release to address this issue. stay tuned.

OK, we will try to improve this in the 3.3.5 release.

Please check error.log and stderr.log for error messages. Increase memory limit see if it helps or not.

freebsd packages has been uploaded.

Maybe next month in the 4.0 release RC2, currently working on the disk cache module.

If you create a context with URI "/", all requests will be forwarded to django. You use a regular expression matching context if you only want to match one URL. http://www.litespeedtech.com/docs/webserver/config/context/

Use "<?php" instead of "<?"

You should create a FastCGI context for each URL that should be handled by the framework. Handler should be set to the python external app. I think you should add "daemonize=false" parameter as well.

3.3.5 release package is available now, you can give it try. just change the version number in the download link.

Correct me if I were wrong, WebDAV requests won't show the content of the file. Actually, only "GET" request could expose the file content. WebDAV requests usually require authentication, so it is not likely a security problem.