Search results

We need to investigate this issue, it could be an issue in our SPDY protocol implementation. Please PM me the page cannot be loaded with 5.0.4, we will try to reproduce the problem in our lab.

We will add that after implementing the @inspectFile. Both operators require interruption of execution flow of ModSecurity rules, which is very hard to implement for a event-driven non-blocking server.

If you turn off Railgun, problem is gone? Railgun agent run on your local server, you may need to add the local IP used by Railgun to connect to web server as trusted IP. Check any error in error log.

The initial build of 5.0.5 is defect. It was fixed later yesterday afternoon. Please try a force reinstall of 5.0.5, if the problem persists, we will investigate.

Please upgrade to 5.0.5 .

We need a copy of the core file to analyze what is the root cause, as we replied to your bug report email.

It sounds like network or kernel TCP stack problem. You can setup a local monitor script to check the delay. from local host and from local LAN. Make sure there is no bandwidth throttling using in LSWS.

LiteSpeed does not support "SecRuleUpdateActionById". Just move that rule to <LocationMatch /wp-login.php> ...</LocationMatch> You can turn on ModSecurity debug logging with "SecDebugLogLevel 9" to find out what happened.

"stuff" refers to SecGeoLookupDb configuration, it wont work with litespeed. GeoIP DB must be set in LiteSpeed native configuration.

Currently it is not supported by modsecurity officially. We will look into that.

Should be available in 5.0.4 release now. /usr/local/lsws/admin/misc/lsup.sh -f -v 5.0.4 You need to configure GeoIP stuff through LiteSpeed Web Console first, ModSecurity's GeoIP related configuration does not work.

Please try 5.0.4 . /usr/local/lsws/admin/misc/lsup.sh -f -v 5.0.4

Yes, if you do not need that, turn if off as it requires accessing Magento framework for each product view.

Probably not, Just wont go with the slower path if have a better choice. Actually, in this case, we will completely separate the rules for different phases. wont mix them together at all. Still one pass processing. Since ModSecurity project keep evolving, our goal is to keep up with it and...

We will have it addressed. Will use libmodsecurity with our openlitespeed product. If it really have better performance than our own re-invented ModSecurity engine, we will switch over if the software license allows.

Like NiteWave mentioned, you have to check phpinfo() output for opcache related configuration when ProcesGroup mode is on. Each account uses different php.ini under CageFS.

OK, I see. The reason is that LiteSpeed combine Phase 1 and Phase 2 and process all rules in one round, when there is no request body. Unless we do two round processing, which is slow, this problem cannot be avoided.

try switching to Apache, then switching to LiteSpeed.

If you have tracking last viewed option turned on, the request still need to reach backend to record the last viewed items. If do not need that, turn it off.

Basically, that module send and flushed the response header, once headers are sent, cannot make changes to headers. You can tune php.ini to use a larger Output Buffer for PHP see if the header can be cached.