Search results

You brought up the RFC compliance, not me. I just posted a bug.

No, it's not my personal logic. It's RFC. Quoted from RFC: "SHOULD process the response as if it had a 5xx" means it HAS to be logged as one too. Process includes logging, if a normal 5xx request is logged by the webserver. Since LS logs them, it should logs invalid statuses too.

You clearly didn't understand anything of what I'm doing. I said I already know how to recognize the ones I need to, because we are expert sysadmins who works vertically on this CMS by years. I don't need any help about it. My only need is that ANY request, bots or not, HAS TO be logged...

Yeah I know. Anyway the RFC you quoted should be applied regardless of the version. So it applies to both. Even OLS replies correctly with my 666 code. it's just that the logging of such request is bugged and doesn't happen. having a correct 666 reply and nothing logged it's clearly a bug. if...

I forgot to say I use LSE not OLS. I expect a correct logging nonetheless. No matter what response code is there. Logging should not have anything to do with following up a request or not. It's just that, logging. About the blocking, this is just one of the solutions in place. These are block...

I see, I read in RFC 2616 it says: I supposed it would work. Well I'll just use 418. Anyway logging, even an unknown response, should always be done. In the logs there isn't even a 500 error in place of my 6xx (or a 600 like RFC says). Not being able to understand the response code doesn't mean...

I use mod_security to return a custom error code 6xx on some requests, so I can later work them with crowdsec actions. However any request with non conventional error codes is not logged at all in the webserver access_log. For example if I have a rule in mod_security that uses deny:403 I get it...

LiteSpeed/1.8.5 Open (BUILD built: Tue Jan 13 22:46:41 UTC 2026) module versions: lsquic 4.4.1 modgzip 1.1 cache 1.66 mod_security 1.4 (with libmodsecurity v3.0.14) Also i found an old thread about this issue. I'm also having only QUIC debug logs apparently...

Ok, I'm also having another problem. Even with log level set to info, warn or debug+none, I still get debug in my error.log, filling the disks. The problem is just like described here...

Sorry to bump this up, but did you find a solution? I'm having the same problem right now and seems like the debug messages are the same.

I'm getting random coredumps on ALL my VPS running Ubuntu. Using gdb and bt I get the following backtrace: [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `openlitesp'. Program terminated with signal...