Search results

and that's why I <3 U (team OLS)

A lossless compressed data format, newer, faster (in de/compressing) than Brotli. Cloudfare uses it. https://github.com/facebook/zstd/blob/dev/doc/zstd_compression_format.md https://facebook.github.io/zstd/

it's http://e6.o.lencr.org now. For future reference just test your SSL enabled domain here to find out its OCSP address

( compared to using sprites + CSS )

Indeed, I managed to make it work from within the OLS webadmin console: Virtual Host -> Context: Type Static | URI: exp:^.*(jpg|jpeg|gif|png|ico|webp|avif|mp4|webm)$ You can add both "Header unset ETag" and "Header unset Set-Cookie" here just be careful which file extensions you list in the...

So in the end what worked? Setting up a listener for IPv4 or just separating it from IPv6 or downgrading to OLS 1.7.15 and then re-upgrading to OLS 1.7.16? I have the same issue with HTTP/3 & QUIC not working, in OLS 1.8.2. Some HTTP/3 checkers like ralfvanveen.com and domsignal.com pass the...

Excellent update @LiteCache ! Is there any other way to implement these 2 unset headers in the OLS Webadmin console, instead of the .htaccess file ? Maybe at the Virtual Host level? Would it work setting them in the Context section of VH as headers, something like in this example of OLS docs ?

5 years later I encounter the same issue. Anyone found a fix for this? (disabling CBC ciphers)

For the moment I downgraded the ModSecurity module to v3.0.12 found in the previous OLS release. So OLS 1.8.2 + mod_security v3.0.12 still works, for anyone encountering this same issue. Take your time devs, but please fix its implementation, going forward. Thank you.

wanted to ask the same thing :) we've been running OLS without mod_security for almost a month now. Should we downgrade or still hold out for a soon to be released update, patch maybe?

Well if you already installed/upgraded to v1.8.2 and you have to ask... you probably don't have it. This would be surprising, if not everybody is affected, meaning probably the issue could be int the rule list? Or perhaps you don't have mod_security plugin activated in the OLS webserver?

Any updates on this issue, please? We have been running the v1.8.2 OLS webserver without ModSecurity, just so it actually displays pages. This is how any and all our web pages are returned (index.html) in Firefox 115.14.0esr (64-bit) when trying to access them (with ModSecurity module enabled):

I also wrote to the ModSecurity dev team on Github: https://github.com/owasp-modsecurity/ModSecurity/issues/3259

Opgraded to OLS v1.8.2 (from v1.7.9), Webadmin works however all my sites get blocked and I encounter 2 (new) issues: 1. the stderr.log gives the following error (same one), every 5 minutes: 2. mod_security now blocks EVERYTHING (browser returns code 301 - moved permanently). When I disable...

I understand. They are all small (PNG) images however, so converting them to AVIF won't help much (or at all). As far as image optimization goes, I found a solution in either to: merge them all into 1 big PNG image, then display them as sprites, with CSS offset & slicing - this way only 1 HTTP...

While on the subject: any tips for faster image transfers under OLS would be greatly appreciated. As you can see, they all take way too long to transfer (see the turtle next to each). What am I doing wrong? (default OLS config) OLS 1.7.19 on Alma Linux 9.4 x64 no cookies, all static content...

I notice every image (jpg, gif), no matter how small is 575 bytes larger when transferred, this due to OLS adding headers to it. Might not seem a lot, but it adds up when you have lots of small images. Is there any way of reducing the header size being added, dare I ask even removing headers...

Intro: CFML is dynamic scrpting language based on Java, widely used - mostly in government infrastructure - while also popular, lesser so than PHP, in the private sector. Currently developed as a propertary App Server by the Adobe Corporation and also as open source (FOSS) by the Switzerland...

Makes sense. Still, caching sometimes brakes the UTF-8 page character encryption, and I have no idea how to trace the problem further. HTML output is always correct, proven by the fact that when LScache is disabled, it always displays correctly, the bad encryption instantly disappears. Any...

A fix would be to be able to check for page encryption errors before displaying the page from cache or disabling/purging cache for said page. Is there any way to do this currently? To check for (cached) page encoding and based on that display it or purge its stored cache version?