Some servers might emit Content-Range header on 200 responses, and this does not seem to contradict RFC 9110: as per RFC 9110, the Content-Range header has no meaning for status codes other than 206 and 416. Previously this resulted in duplicate Content-Range headers in nginx responses handled by the range filter. Fix is to clear pre-existing headers.
To ensure optimal use of memory, SSL contexts for proxying are now inherited from previous levels as long as relevant proxy_ssl_* directives are not redefined. Further, when no proxy_ssl_* directives are redefined in a server block, we now preserve plcf->upstream.ssl in the "http" section configuration to inherit it to all servers. Similar changes made in uwsgi, grpc, and stream proxy.
Both "count" and "duration" variables are 32-bit, so their product might potentially overflow. It is used to reduce 64-bit start_time variable, and with very large start_time this can result in incorrect seeking. Found by Coverity (CID 1499904).
Now, if the directive is given an empty string, such configuration cancels loading of certificates, in particular, if they would be otherwise inherited from the previous level. This restores previous behaviour, before variables support in certificates was introduced (3ab8e1e2f0f7).
Previously, if caching was disabled due to Expires in the past, nginx failed to cache the response even if it was cacheable as per subsequently parsed Cache-Control header (ticket #964). Similarly, if caching was disabled due to Expires in the past, "Cache-Control: no-cache" or "Cache-Control: max-age=0", caching was not used if it was cacheable as per subsequently parsed X-Accel-Expires header. Fix is to avoid disabling caching immediately after parsing Expires in the past or Cache-Control, but rather set flags which are later checked by ngx_http_upstream_process_headers() (and cleared by "Cache-Control: max-age" and X-Accel-Expires). Additionally, now X-Accel-Expires does not prevent parsing of cache control extensions, notably stale-while-revalidate and stale-if-error. This ensures that order of the X-Accel-Expires and Cache-Control headers is not important. Prodded by Vadim Fedorenko and Yugo Horie.
If a module adds multiple WWW-Authenticate headers (ticket #485) to the response, linked in r->headers_out.www_authenticate, all headers are now cleared if another module later allows access. This change is a nop for standard modules, since the only access module which can add multiple WWW-Authenticate headers is the auth request module, and it is checked after other standard access modules. Though this might affect some third party access modules. Note that if a 3rd party module adds a single WWW-Authenticate header and not yet modified to set the header's next pointer to NULL, attempt to clear such a header with this change will result in a segmentation fault.
When using auth_request with an upstream server which returns 401 (Unauthorized), multiple WWW-Authenticate headers from the upstream server response are now properly copied to the response.