Found by Coverity (CID 1467637).
In 7717:e3e8b8234f05, the 1st bit was incorrectly used. It shouldn't be used for bitmask values, as it is used by NGX_CONF_BITMASK_SET. Additionally, special value "off" added to make it possible to clear inherited userid_flags value.
This is in preparation for the next change. Also, moved optimization from ngx_http_proxy_rewrite_regex_handler() to ngx_http_proxy_rewrite().
The "false" parameter of the proxy_redirect directive is deprecated. Warning has been emitted since c2230102df6f (0.7.54). The "off" parameter of the proxy_redirect, proxy_cookie_domain, and proxy_cookie_path directives tells nginx not to inherit the configuration from the previous configuration level. Previously, after specifying the directive with the "off" parameter, any other directives were ignored, and syntax checking was disabled. The syntax was enforced to allow either one directive with the "off" parameter, or several directives with other parameters. Also, specifying "proxy_redirect default foo" no longer works like "proxy_redirect default".
After 05e42236e95b (1.19.1) responses with extra data might result in zero size buffers being generated and "zero size buf" alerts in writer (if f->rest happened to be 0 when processing additional stdout data).
Previously, the document generated by the xslt filter was always fully sent to client even if a range was requested and response status was 206 with appropriate Content-Range. The xslt module is unable to serve a range because of suspending the header filter chain. By the moment full response xml is buffered by the xslt filter, range header filter is not called yet, but the range body filter has already been called and did nothing. The fix is to disable ranges by resetting the r->allow_ranges flag much like the image filter that employs a similar technique.
The slice filter allows ranges for the response by setting the r->allow_ranges flag, which enables the range filter. If the range was not requested, the range filter adds an Accept-Ranges header to the response to signal the support for ranges. Previously, if an Accept-Ranges header was already present in the first slice response, client received two copies of this header. Now, the slice filter removes the Accept-Ranges header from the response prior to setting the r->allow_ranges flag.
As long as the "Content-Length" header is given, we now make sure it exactly matches the size of the response. If it doesn't, the response is considered malformed and must not be forwarded (https://tools.ietf.org/html/rfc7540#section-8.1.2.6). While it is not really possible to "not forward" the response which is already being forwarded, we generate an error instead, which is the closest equivalent. Previous behaviour was to pass everything to the client, but this seems to be suboptimal and causes issues (ticket #1695). Also this directly contradicts HTTP/2 specification requirements. Note that the new behaviour for the gRPC proxy is more strict than that applied in other variants of proxying. This is intentional, as HTTP/2 specification requires us to do so, while in other types of proxying malformed responses from backends are well known and historically tolerated.