QS_EventPerSecLimit have no effect

[Ahmed Ahmed]

I have this simple configuration here:-

SetEnvIfExpr "%{HTTP:userId} =~ /([0-9]*)/" USER_ID=$1
CustomLog "logs/custom.log" "USER_ID=%{USER_ID}e"
QS_EventPerSecLimit USER_ID 10

And the rate rate limiting is not there at all, I checked the source code and All I could find is that sconf->location_t is getting assigned in the qos_event_rs_cmd function but it never got used for actual rate limiting anywhere.

Also many other rate limiting directives there that just modify the sconf variable for the qs_hp_ccfunction to use it for rate limiting, they end up having no effect as the time calculation used to get the rate per second suffers overflows for some reason, the time calculation uses now > (*clientEntry)->interval, and both of those variables overflow.

My best guess here is that in the current year which is 2024, the Epoch timestamp that apr_time_sec produces is so big that the apr_time_t can't hold it and just overflows.

[Pascal Buchbinder]

QS_EventPerSecLimit measures the current "requests per time interval" (default is 5 seconds https://mod-qos.sourceforge.net/#QS_SrvSampleRate) and calculates and applies a delay if necessary, https://mod-qos.sourceforge.net/glossary.html#requestPerSecond

You should see "mod_qos(050): request rate limit" messages if a delay gets added. You can also watch the the calculated request rate using the status viewer (mod_status) or measure it by counting the log lines matching your rule (per five seconds).

[Ahmed Ahmed]

Yes, the problem is that the calculation for requests per time interval uses timestamps, and they are seconds that have passed from the default year of 1970, this number increases everyday, and now it overflows the datatypes used in the project, specially the apr_time_t.

This happens to me with the official docker images.

[Pascal Buchbinder]

don't worry, apr_time_t is a 64bit (long or long long depending on your OS)
you probably think about the year 2038 bug where 32bit integers will overflow