Search results

this email was sent out 1 day ago, it's about bug for lsws 4.2.1. since you have upgraded to 4.2.2, should be no 4.2.1 related bug report any more.

run "top -c": I killed the process by #kill 27128 like I did last time. please see if email still coming in. please try to upgrade to 4.2.2 manually. it fixed a few mod_security bugs and likely including yours. #cd /usr/local/lsws/admin/misc #./lsup.sh -v 4.2.2

thanks for the update. mark as [solved] related thread: http://www.litespeedtech.com/support/forum/showthread.php?t=5765

Thanks for the update! to summary: 1. root cause is ZendGuardLoader 2. best not load ZendGuardLoader.so if not really need it 3.if have to load ZendGuardLoader, then above is a workaround to modify the source code of Gallery 3!

give a screenshot of lsws admin console->Server->Cache

http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html rewriterule has a bit difference in per-server or per-directory context. ==> in short, need add some / in some rewriterules

1 CPU or 1 core license is ok. since VPS license has a 2G memory limit.

standard version has 150 concurrent connections limit for VPS license the limit is 500 for other license, no connection limit. more detail info can be found here: http://www.litespeedtech.com/litespeed-web-server-editions.html your question: can litespeed handle 50k -- 100k concurrent...

this looks a good post regarding test cookie: http://umumble.com/blogs/Infosecurity/538/ litespeed's built-in anti-ddos has been approved to be effective to mitigate DDOS in many scenarios, but of course, it's not effective in all cases. in fact, litespeed already has javascript based...

there is some built-in anti-ddos feature in litespeed: http://www.litespeedtech.com/docs/webserver/config/security/#perClientConnLimit it's efficient and effective in real-world testing, for years.

it looks like %(ENV:REDIRECT_STATUS} in rewriterule is an undocumented feature in apache. if so, not recommend to use it. http://httpd.apache.org/docs/current/mod/mod_rewrite.html apache 2.3.9, introduced a new rewrite flag "END" looks it acts exactly as litespeed's "LAST" or "L" flag.

Thanks for the update. will mark [solved]

tested, following rewrite rules meet your requirement: maybe there is other work around, but in above example, have introduced litespeed's special %{ORG_REQ_URI} which differ with %{REQUEST_URI} in that it's the original request URI --- do not change during rewrite process. and with...

I did following tests with lsws, it's working as expected: RewriteEngine On RewriteCond %{THE_REQUEST} ^(?:post|get)\ /genkey/[0-9a-f]{32} [NC] RewriteRule .* /keygenerator.php [L] RewriteRule .* /restricted.php [L] no recursive loop. and no need ENV:REDIRECT_STATUS...

I'm not test yet, but likely litepeed won't set this environment variable(i.e.,"REDIRECT_STATUS") automatically. this is the ultimate goal. I think litespeed is doing better(higher performance and less confusing) in this regards by my experience. can you give an example rewriterule, which you...

this may be where the problem is. please check .htaccess, any directive like suPHP_UserGroup in it

looks no reply from bettinz. it's best bettinz can update this post. that's no known performance issue so far regarding suExec Daemon + CaseFS but phpSeletor which working with apache not working with litespeed yet -- CloudLinux and litespeed will co-operate to work on this. one known poor...

so can you set the environment variable on T-WAF ? the frontend and backend litespeed better to set to keep alive i.e., set litespeed Max Keep-Alive Requests to default value

1)any improvement regarding the error rate before and after the change? 2)any URL pattern or method(GET or POST) which is easier to trigger the error or just random ? 3)will the same error happen between T-WAF proxy and other web server(apache, nginx etc)? again, it'll be much helpful...

it should be compatible. you have to try and see to know the exact answer.