In limit_req, auth_delay, and upstream code to check for broken connections, tests for possible connection close by the client did not work if the connection was already closed when relevant event handler was set. This happened because there were no additional events in case of edge-triggered event methods, and read events were disabled in case of level-triggered ones. Fix is to explicitly post a read event if the c->read->ready flag is set.
Previously, if there were multiple limits configured, errors in ngx_http_complex_value() during processing of a non-first limit resulted in reference count leak in shared memory nodes of already processed limits. Fix is to explicity unlock relevant nodes, much like we do when rejecting requests.
The variable takes one of the values: PASSED, DELAYED, REJECTED, DELAYED_DRY_RUN or REJECTED_DRY_RUN.
A new directive limit_req_dry_run allows enabling the dry run mode. In this mode requests are neither rejected nor delayed, but reject/delay status is logged as usual.
This parameter specifies an additional "soft" burst limit at which requests become delayed (but not yet rejected as it happens if "burst=" limit is exceeded). Defaults to 0, i.e., all excess requests are delayed. Originally inspired by Vladislav Shabanov (http://mailman.nginx.org/pipermail/nginx-devel/2016-April/008126.html). Further improved based on a patch by Peter Shchuchkin (http://mailman.nginx.org/pipermail/nginx-devel/2018-October/011522.html).
Negative times can appear since workers only update time on an event loop iteration start. If a worker was blocked for a long time during an event loop iteration, it is possible that another worker already updated the time stored in the node. As such, time since last update of the node (ms) will be negative. Previous code used ngx_abs(ms) in the calculations. That is, negative times were effectively treated as positive ones. As a result, it was not possible to maintain high request rates, where the same node can be updated multiple times from during an event loop iteration. In particular, this affected setups with many SSL handshakes, see http://mailman.nginx.org/pipermail/nginx/2018-May/056291.html. Fix is to only update the last update time stored in the node if the new time is larger than previously stored one. If a future time is stored in the node, we preserve this time as is. To prevent breaking things on platforms without monotonic time available if system time is updated backwards, a safety limit of 60 seconds is used. If the time stored in the node is more than 60 seconds in the future, we assume that the time was changed backwards and update lr->last to the current time.
With post_action or subrequests, it is possible that the timer set for wev->delayed will expire while the active subrequest write event handler is not ready to handle this. This results in request hangs as observed with limit_rate / sendfile_max_chunk and post_action (ticket #776) or subrequests (ticket #1228). Moving the handling to the connection event handler fixes the hangs observed, and also slightly simplifies the code.
Since limit_req uses connection's write event to delay request processing, it can conflict with timers in other subrequests. In particular, even if applied to an active subrequest, it can break things if wev->delayed is already set (due to limit_rate or sendfile_max_chunk), since after limit_req finishes the wev->delayed flag will be set and no timer will be active. Fix is to use the wev->delayed flag in limit_req as well. This ensures that wev->delayed won't be set after limit_req finishes, and also ensures that limit_req's timers will be properly handled by other subrequests if the one delayed by limit_req is not active.