Previous interface of ngx_open_dir() assumed that passed directory name has a room for NGX_DIR_MASK at the end (NGX_DIR_MASK_LEN bytes). While all direct users of ngx_dir_open() followed this interface, this also implied similar requirements for indirect uses - in particular, via ngx_walk_tree(). Currently none of ngx_walk_tree() uses provides appropriate space, and fixing this does not look like a right way to go. Instead, ngx_dir_open() interface was changed to not require any additional space and use appropriate allocations instead.
Previously, AF_UNIX addresses misbehaved as AF_INET, which typically resulted in $uid_set composed from the middle of sun_path.
Previously, AF_UNIX client addresses were handled as AF_INET, leading to unexpected results.
Previously, unnamed regex captures matched in the parent request, were not available in a cloned subrequest. Now 3 fields related to unnamed captures are copied to a cloned subrequest: r->ncaptures, r->captures and r->captures_data. Since r->captures cannot be changed by either request after creating a clone, a new flag r->realloc_captures is introduced to force reallocation of r->captures. The issue was reported as a proxy_cache_background_update misbehavior in http://mailman.nginx.org/pipermail/nginx/2018-December/057251.html.
In the past, there were several security issues which resulted in worker process memory disclosure due to buffers with negative size. It looks reasonable to check for such buffers in various places, much like we already check for zero size buffers. While here, removed "#if 1 / #endif" around zero size buffer checks. It looks highly unlikely that we'll disable these checks anytime soon.
On 32-bit platforms mp4->buffer_pos might overflow when a large enough (close to 4 gigabytes) atom is being skipped, resulting in incorrect memory addesses being read further in the code. In most cases this results in harmless errors being logged, though may also result in a segmentation fault if hitting unmapped pages. To address this, ngx_mp4_atom_next() now only increments mp4->buffer_pos up to mp4->buffer_end. This ensures that overflow cannot happen.
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).