In ngx_http_range_singlepart_body() special buffers where passed unmodified, including ones after the end of the range. As such, if the last buffer of a response was sent separately as a special buffer, two buffers with b->last_buf set were present in the response. In particular, this might result in a duplicate final chunk when using chunked transfer encoding (normally range filter and chunked transfer encoding are not used together, but this may happen if there are trailers in the response). This also likely to cause problems in HTTP/2. Fix is to skip all special buffers after we've sent the last part of the range requested. These special buffers are not meaningful anyway, since we set b->last_buf in the buffer with the last part of the range, and everything is expected to be flushed due to it. Additionally, ngx_http_next_body_filter() is now called even if no buffers are to be passed to it. This ensures that various write events are properly propagated through the filter chain. In particular, this fixes test failures observed with the above change and aio enabled.
Filters are not allowed to change incoming chain links, and should allocate their own links if any modifications are needed. Nevertheless ngx_http_range_singlepart_body() modified incoming chain links in some cases, notably at the end of the requested range. No problems caused by this are currently known, mostly because of limited number of possible modifications and the position of the range body filter in the filter chain. Though this behaviour is clearly incorrect and tests demonstrate that it can at least cause some proxy buffers being lost when using proxy_force_ranges, leading to less effective handling of responses. Fix is to always allocate new chain links in ngx_http_range_singlepart_body(). Links are explicitly freed to ensure constant memory usage with long-lived requests.
If a complex value is expected to be of type size_t, and the compiled value is constant, the constant size_t value is remembered at compile time. The value is accessed through ngx_http_complex_value_size() which either returns the remembered constant or evaluates the expression and parses it as size_t.
Previously, ngx_utf8_decode() was called from ngx_utf8_length() with incorrect length, potentially resulting in out-of-bounds read when handling invalid UTF-8 strings. In practice out-of-bounds reads are not possible though, as autoindex, the only user of ngx_utf8_length(), provides null-terminated strings, and ngx_utf8_decode() anyway returns an errors when it sees a null in the middle of an UTF-8 sequence. Reported by Yunbin Liu.
If OCSP stapling was enabled with dynamic certificate loading, with some OpenSSL versions (1.0.2o and older, 1.1.0h and older; fixed in 1.0.2p, 1.1.0i, 1.1.1) a segmentation fault might happen. The reason is that during an abbreviated handshake the certificate callback is not called, but the certificate status callback was called (https://github.com/openssl/openssl/issues/1662), leading to NULL being returned from SSL_get_certificate(). Fix is to explicitly check SSL_get_certificate() result.