Search results

@edan I did report the issue in form of a ticket back in January but haven't heard back so far. Flagged requests are so far still forwarded by OLS in reverse proxy mode.

So far I couldn't find a solution to allow OCSP lookups for OCSP stapling in a locked down environment, e.g. with an outbound firewall configured. Explicitly allowing outgoing requests for OCSP responders is not an option, as IPs for these are not static and can rapidly change (see for example...

As discussed in the generic topic Proxy extension and HTTP/2, the proxy extension currently only supports HTTP/1.x in back-end communication. Support for HTTP/2 (and ideally HTTP/3 w/ QUIC transport as well) could increase throughput and improve general performance for reverse proxy...

@lsqtwrk thank you for the feedback, that pretty much confirms my test results. I'll add a feature request for this then, I'm pretty sure that this will become one of the performance features for OLS and LiteSpeed Enterprise in the future that will attract users and customers alike, as consumer...

@gilles Each vhost has at least some unique setting that I couldn't generically configure in a vhost template (mostly reverse proxy configurations with different back-end servers, external applications and/or rewrite rules). In this regard (off-topic for this feature request though) I would...

With several vhosts configured that share many common settings, it would be very practical to be able to configure access log properties centrally. During tests with no access log setting except for the file name configured for the vhosts, only the global log format setting seems to be...

I was testing out whether I could get a full HTTP/2 chain working with OpenLiteSpeed 1.7.8 acting as a reverse proxy. Clients successfully establish HTTP/2 connections to OpenLiteSpeed, but despite HTTPS being configured for the proxied web server / external application, OLS connects to the...

@Cold-Egg thank you, I raised a ticket. mod_security itself works fine, the WAF violations are reported correctly (as in your log excerpt). The problem is that the proxy context is nonetheless fully executed instead of immediately blocking the request with the mod_security raised status code.

@Cold-Egg thank you for the quick reply. I switched to the edge repository and upgraded to version 1.7.8. The behaviour is exactly the same, for local files the mod_security intervention works as it should, for requests with a proxy configured mod_security logs an intervention but OLS...

I ran into the same issue. OLS 1.6.19 is set up with mod_security globally enabled using the Comodo WAF ruleset. When a local file is requested during tests, mod_security reports the match and triggers an intervention status code. OLS responses with the new status code. So far, so good. If the...