It now uses custom alloc_aligned() wrapper for all allocations,
therefore all allocations are larger than expected by (64 + sizeof(void*)).
Further, they are seen as allocations of 1 element.  Relevant calculations
were adjusted to reflect this, and state allocation is now protected
with a flag to avoid misinterpreting other allocations as the zlib
deflate_state allocation.

Further, it no longer forces window bits to 13 on compression level 1,
so the comment was adjusted to reflect this.

Similarly to 7192:d5a535774861, this avoids spurious zero statuses
in access.log, and in line with other header-related errors.

Similarly to ticket #274 (7354:1812f1d79d84), early request finalization
without calling ngx_http_run_posted_requests() resulted in a connection
hang (a socket leak) if the 400 (Bad Request) error was generated in
ngx_http_v2_state_process_header() due to invalid request headers and
"return 444" was used in error_page 400.

This is expected to help with clients using pipelining with some constant
depth, such as apt[1][2].

When downloading many resources, apt uses pipelining with some constant
depth, a number of requests in flight.  This essentially means that after
receiving a response it sends an additional request to the server, and
this can result in requests arriving to the server at any time.  Further,
additional requests are sent one-by-one, and can be easily seen as such
(neither as pipelined, nor followed by pipelined requests).

The only safe approach to close such connections (for example, when
keepalive_requests is reached) is with lingering.  To do so, now nginx
monitors if pipelining was used on the connection, and if it was, closes
the connection with lingering.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973861#10
[2] https://mailman.nginx.org/pipermail/nginx-devel/2023-January/ZA2SP5SJU55LHEBCJMFDB2AZVELRLTHI.html

Since 4611:2b6cb7528409 responses from the gzip static, flv, and mp4 modules
can be used with subrequests, though empty files were not properly handled.
Empty gzipped, flv, and mp4 files thus resulted in "zero size buf in output"
alerts.  While valid corresponding files are not expected to be empty, such
files shouldn't result in alerts.

Fix is to set b->sync on such empty subrequest responses, similarly to what
ngx_http_send_special() does.

Additionally, the static module, the ngx_http_send_response() function, and
file cache are modified to do the same instead of not sending the response
body at all in such cases, since not sending the response body at all is
believed to be at least questionable, and might break various filters
which do not expect such behaviour.

The "listen" directive in the http module can be used multiple times
in different server blocks.  Originally, it was supposed to be specified
once with various socket options, and without any parameters in virtual
server blocks.  For example:

    server { listen 80 backlog=1024; server_name foo; ... }
    server { listen 80; server_name bar; ... }
    server { listen 80; server_name bazz; ... }

The address part of the syntax ("address[:port]" / "port" / "unix:path")
uniquely identifies the listening socket, and therefore is enough for
name-based virtual servers (to let nginx know that the virtual server
accepts requests on the listening socket in question).

To ensure that listening options do not conflict between virtual servers,
they were allowed only once.  For example, the following configuration
will be rejected ("duplicate listen options for 0.0.0.0:80 in ..."):

    server { listen 80 backlog=1024; server_name foo; ... }
    server { listen 80 backlog=512; server_name bar; ... }

At some point it was, however, noticed, that it is sometimes convenient
to repeat some options for clarity.  In nginx 0.8.51 the "ssl" parameter
was allowed to be specified multiple times, e.g.:

    server { listen 443 ssl backlog=1024; server_name foo; ... }
    server { listen 443 ssl; server_name bar; ... }
    server { listen 443 ssl; server_name bazz; ... }

This approach makes configuration more readable, since SSL sockets are
immediately visible in the configuration.  If this is not needed, just the
address can still be used.

Later, additional protocol-specific options similar to "ssl" were
introduced, notably "http2" and "proxy_protocol".  With these options,
one can write:

    server { listen 443 ssl backlog=1024; server_name foo; ... }
    server { listen 443 http2; server_name bar; ... }
    server { listen 443 proxy_protocol; server_name bazz; ... }

The resulting socket will use ssl, http2, and proxy_protocol, but this
is not really obvious from the configuration.

To emphasize such misleading configurations are discouraged, nginx now
warns as long as the "listen" directive is used with options different
from the options previously used if this is potentially confusing.

In particular, the following configurations are allowed:

    server { listen 8401 ssl backlog=1024; server_name foo; }
    server { listen 8401 ssl; server_name bar; }
    server { listen 8401 ssl; server_name bazz; }

    server { listen 8402 ssl http2 backlog=1024; server_name foo; }
    server { listen 8402 ssl; server_name bar; }
    server { listen 8402 ssl; server_name bazz; }

    server { listen 8403 ssl; server_name bar; }
    server { listen 8403 ssl; server_name bazz; }
    server { listen 8403 ssl http2; server_name foo; }

    server { listen 8404 ssl http2 backlog=1024; server_name foo; }
    server { listen 8404 http2; server_name bar; }
    server { listen 8404 http2; server_name bazz; }

    server { listen 8405 ssl http2 backlog=1024; server_name foo; }
    server { listen 8405 ssl http2; server_name bar; }
    server { listen 8405 ssl http2; server_name bazz; }

    server { listen 8406 ssl; server_name foo; }
    server { listen 8406; server_name bar; }
    server { listen 8406; server_name bazz; }

And the following configurations will generate warnings:

    server { listen 8501 ssl http2 backlog=1024; server_name foo; }
    server { listen 8501 http2; server_name bar; }
    server { listen 8501 ssl; server_name bazz; }

    server { listen 8502 backlog=1024; server_name foo; }
    server { listen 8502 ssl; server_name bar; }

    server { listen 8503 ssl; server_name foo; }
    server { listen 8503 http2; server_name bar; }

    server { listen 8504 ssl; server_name foo; }
    server { listen 8504 http2; server_name bar; }
    server { listen 8504 proxy_protocol; server_name bazz; }

    server { listen 8505 ssl http2 proxy_protocol; server_name foo; }
    server { listen 8505 ssl http2; server_name bar; }
    server { listen 8505 ssl; server_name bazz; }

    server { listen 8506 ssl http2; server_name foo; }
    server { listen 8506 ssl; server_name bar; }
    server { listen 8506; server_name bazz; }

    server { listen 8507 ssl; server_name bar; }
    server { listen 8507; server_name bazz; }
    server { listen 8507 ssl http2; server_name foo; }

    server { listen 8508 ssl; server_name bar; }
    server { listen 8508; server_name bazz; }
    server { listen 8508 ssl backlog=1024; server_name foo; }

    server { listen 8509; server_name bazz; }
    server { listen 8509 ssl; server_name bar; }
    server { listen 8509 ssl backlog=1024; server_name foo; }

The basic idea is that at most two sets of protocol options are allowed:
the main one (with socket options, if any), and a shorter one, with options
being a subset of the main options, repeated for clarity.  As long as the
shorter set of protocol options is used, all listen directives except the
main one should use it.

Previously, location prefix length in ngx_http_location_tree_node_t was
stored as "u_char", and therefore location prefixes longer than 255 bytes
were handled incorrectly.

Fix is to use "u_short" instead.  With "u_short", prefixes up to 65535 bytes
can be safely used, and this isn't reachable due to NGX_CONF_BUFFER, which
is 4096 bytes.

In contrast to on-the-fly gzipping with gzip filter, static gzipped
representation as returned by gzip_static is persistent, and therefore
the same binary representation is available for future requests, making
it possible to use range requests.

Further, if a gzipped representation is re-generated with different
compression settings, it is expected to result in different ETag and
different size reported in the Content-Range header, making it possible
to safely use range requests anyway.

As such, ranges are now allowed for files returned by gzip_static.