If a buffered request body wasn't fully sent, such as on early upstream
response or limited by flow control, unsent buffers could remain in the
input or busy chains when switching to the next upstream server.  This
resulted either in the invalid request sent or a stalled connection.

The fix is to reset chains similar to ngx_http_upstream_reinit().

A total response length with multiple ranges can be larger than the
source response size due to multipart boundary headers.  This change
extends max ranges limit imposed in c2c3e3105 (1.1.2) by accounting
boundary headers.  Notably, this covers suspicious requests with a
lot of small ranges that have an increased processing overhead and
are susceptible to range based amplification attacks.

The limit disables ranges as long as a total response length comes
close to the source size, additionally penalizing small size ranges
on a large source size where a processing overhead prevails, while
leaving a room for more ranges on a small source size, such that it
should not affect well-behaving applications.  The limit can be
altered with the "max_ranges" directive.

Closes #988 on GitHub.

Previously, the HTTP_HOST environment variable was constructed from the
Host request header field, which doesn't work well with HTTP/2 and
HTTP/3 where Host may be supplanted by the ":authority" pseudo-header
field per RFC 9110, section 7.2. Also, it might give an incorrect
HTTP_HOST value from HTTP/1.x requests given in the absolute form, in
which case the Host header must be ignored by the server, per RFC 9112,
section 3.2.2.

The fix is to redefine the HTTP_HOST default from a protocol-specific
value given in the $host variable. This will now use the Host request
header field, ":authority" pseudo-header field, or request line target
URI depending on request HTTP version.

Also the CGI specification (RFC 3875, 4.1.18) notes

  The server SHOULD set meta-variables specific to the protocol and
  scheme for the request. Interpretation of protocol-specific
  variables depends on the protocol version in SERVER_PROTOCOL.

Previously, the HTTP_HOST environment variable was constructed from the
Host request header field, which doesn't work well with HTTP/2 and
HTTP/3 where Host may be supplanted by the ":authority" pseudo-header
field per RFC 9110, section 7.2. Also, it might give an incorrect
HTTP_HOST value from HTTP/1.x requests given in the absolute form, in
which case the Host header must be ignored by the server, per RFC 9112,
section 3.2.2.

The fix is to redefine the HTTP_HOST default from a protocol-specific
value given in the $host variable. This will now use the Host request
header field, ":authority" pseudo-header field, or request line target
URI depending on request HTTP version.

Also the CGI specification (RFC 3875, 4.1.18) notes

  The server SHOULD set meta-variables specific to the protocol and
  scheme for the request. Interpretation of protocol-specific
  variables depends on the protocol version in SERVER_PROTOCOL.

Previously, the HTTP_HOST environment variable was constructed from the
Host request header field, which doesn't work well with HTTP/2 and
HTTP/3 where Host may be supplanted by the ":authority" pseudo-header
field per RFC 9110, section 7.2. Also, it might give an incorrect
HTTP_HOST value from HTTP/1.x requests given in the absolute form, in
which case the Host header must be ignored by the server, per RFC 9112,
section 3.2.2.

The fix is to redefine the HTTP_HOST default from a protocol-specific
value given in the $host variable. This will now use the Host request
header field, ":authority" pseudo-header field, or request line target
URI depending on request HTTP version.

Also the CGI specification (RFC 3875, 4.1.18) notes

  The server SHOULD set meta-variables specific to the protocol and
  scheme for the request. Interpretation of protocol-specific
  variables depends on the protocol version in SERVER_PROTOCOL.

Closes: https://github.com/nginx/nginx/issues/256
Closes: https://github.com/nginx/nginx/issues/455
Closes: https://github.com/nginx/nginx/issues/912

The module allows to use HTTP/2 protocol for proxying.
HTTP/2 proxying is enabled by specifying "proxy_http_version 2".

Example:

    server {
        listen 8000;

        location / {
            proxy_http_version 2;
            proxy_pass https://127.0.0.1:8443;
        }
    }

    server {
        listen 8443 ssl;
        http2 on;

        ssl_certificate certs/example.com.crt;
        ssl_certificate_key certs/example.com.key;

        location / {
            return 200 foo;
        }
    }