<feed xmlns='http://www.w3.org/2005/Atom'>
<title>nginx.git/src/http/ngx_http.c, branch release-1.30.0</title>
<subtitle>nginx</subtitle>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/'/>
<entry>
<title>The "multipath" parameter of the "listen" directive.</title>
<updated>2026-03-18T21:13:51+00:00</updated>
<author>
<name>Sergey Kandaurov</name>
<email>pluknet@nginx.com</email>
</author>
<published>2025-10-16T15:22:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=920dc099c130e0ea23eb36becd157a95901aa5a2'/>
<id>920dc099c130e0ea23eb36becd157a95901aa5a2</id>
<content type='text'>
When configured, it enables Multipath TCP support on a listen socket.
As of now it works on Linux starting with Linux 5.6 and glibc 2.32,
where it is enabled with an IPPROTO_MPTCP socket(2) protocol.

To avoid EADDRINUSE errors in bind() and listen() when transitioning
between sockets with different protocols, SO_REUSEPORT is set on both
sockets.  See f7f1607bf for potential implications.

Based on previous work by Maxime Dourov and Anthony Doeraene.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When configured, it enables Multipath TCP support on a listen socket.
As of now it works on Linux starting with Linux 5.6 and glibc 2.32,
where it is enabled with an IPPROTO_MPTCP socket(2) protocol.

To avoid EADDRINUSE errors in bind() and listen() when transitioning
between sockets with different protocols, SO_REUSEPORT is set on both
sockets.  See f7f1607bf for potential implications.

Based on previous work by Maxime Dourov and Anthony Doeraene.
</pre>
</div>
</content>
</entry>
<entry>
<title>Upstream: early hints support.</title>
<updated>2025-06-19T06:19:57+00:00</updated>
<author>
<name>Roman Arutyunyan</name>
<email>arut@nginx.com</email>
</author>
<published>2024-11-15T04:23:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=662c1dd2a97afd6c7ca09b8f5a74347ee017b86b'/>
<id>662c1dd2a97afd6c7ca09b8f5a74347ee017b86b</id>
<content type='text'>
The change implements processing upstream early hints response in
ngx_http_proxy_module and ngx_http_grpc_module.  A new directive
"early_hints" enables sending early hints to the client.  By default,
sending early hints is disabled.

Example:

    map $http_sec_fetch_mode $early_hints {
        navigate $http2$http3;
    }

    early_hints $early_hints;

    proxy_pass http://example.com;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The change implements processing upstream early hints response in
ngx_http_proxy_module and ngx_http_grpc_module.  A new directive
"early_hints" enables sending early hints to the client.  By default,
sending early hints is disabled.

Example:

    map $http_sec_fetch_mode $early_hints {
        navigate $http2$http3;
    }

    early_hints $early_hints;

    proxy_pass http://example.com;
</pre>
</div>
</content>
</entry>
<entry>
<title>Common tree insert function for QUIC and UDP connections.</title>
<updated>2023-05-14T08:30:11+00:00</updated>
<author>
<name>Roman Arutyunyan</name>
<email>arut@nginx.com</email>
</author>
<published>2023-05-14T08:30:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=0a3c79614521d7612b63eff4e09c25ed219fb65b'/>
<id>0a3c79614521d7612b63eff4e09c25ed219fb65b</id>
<content type='text'>
Previously, ngx_udp_rbtree_insert_value() was used for plain UDP and
ngx_quic_rbtree_insert_value() was used for QUIC.  Because of this it was
impossible to initialize connection tree in ngx_create_listening() since
this function is not aware what kind of listening it creates.

Now ngx_udp_rbtree_insert_value() is used for both QUIC and UDP.  To make
is possible, a generic key field is added to ngx_udp_connection_t.  It keeps
client address for UDP and connection ID for QUIC.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previously, ngx_udp_rbtree_insert_value() was used for plain UDP and
ngx_quic_rbtree_insert_value() was used for QUIC.  Because of this it was
impossible to initialize connection tree in ngx_create_listening() since
this function is not aware what kind of listening it creates.

Now ngx_udp_rbtree_insert_value() is used for both QUIC and UDP.  To make
is possible, a generic key field is added to ngx_udp_connection_t.  It keeps
client address for UDP and connection ID for QUIC.
</pre>
</div>
</content>
</entry>
<entry>
<title>HTTP/3: removed "http3" parameter of "listen" directive.</title>
<updated>2023-05-11T09:22:10+00:00</updated>
<author>
<name>Roman Arutyunyan</name>
<email>arut@nginx.com</email>
</author>
<published>2023-05-11T09:22:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=2ce3eeeeb76318e414b62d399da70872d2de23d8'/>
<id>2ce3eeeeb76318e414b62d399da70872d2de23d8</id>
<content type='text'>
The parameter has been deprecated since c851a2ed5ce8.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The parameter has been deprecated since c851a2ed5ce8.
</pre>
</div>
</content>
</entry>
<entry>
<title>Merged with the default branch.</title>
<updated>2023-03-29T07:14:25+00:00</updated>
<author>
<name>Sergey Kandaurov</name>
<email>pluknet@nginx.com</email>
</author>
<published>2023-03-29T07:14:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=e8fbc967470b39513248cd961ccccf7a032831ea'/>
<id>e8fbc967470b39513248cd961ccccf7a032831ea</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Added warning about redefinition of listen socket protocol options.</title>
<updated>2023-01-27T22:29:45+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2023-01-27T22:29:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=dad65f3e449f215469943628f2b1f12a118fcf7e'/>
<id>dad65f3e449f215469943628f2b1f12a118fcf7e</id>
<content type='text'>
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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.
</pre>
</div>
</content>
</entry>
<entry>
<title>HTTP/3: "quic" parameter of "listen" directive.</title>
<updated>2023-02-27T10:00:56+00:00</updated>
<author>
<name>Roman Arutyunyan</name>
<email>arut@nginx.com</email>
</author>
<published>2023-02-27T10:00:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=815ef96124176baef4e940c4beaec158305b368a'/>
<id>815ef96124176baef4e940c4beaec158305b368a</id>
<content type='text'>
Now "listen" directve has a new "quic" parameter which enables QUIC protocol
for the address.  Further, to enable HTTP/3, a new directive "http3" is
introduced.  The hq-interop protocol is enabled by "http3_hq" as before.
Now application protocol is chosen by ALPN.

Previously used "http3" parameter of "listen" is deprecated.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Now "listen" directve has a new "quic" parameter which enables QUIC protocol
for the address.  Further, to enable HTTP/3, a new directive "http3" is
introduced.  The hq-interop protocol is enabled by "http3_hq" as before.
Now application protocol is chosen by ALPN.

Previously used "http3" parameter of "listen" is deprecated.
</pre>
</div>
</content>
</entry>
<entry>
<title>Fixed handling of very long locations (ticket #2435).</title>
<updated>2023-01-26T00:34:44+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2023-01-26T00:34:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=f20c6e0eb5820574417106ca5c0863a1ebbe03a7'/>
<id>f20c6e0eb5820574417106ca5c0863a1ebbe03a7</id>
<content type='text'>
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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.
</pre>
</div>
</content>
</entry>
<entry>
<title>QUIC: separate UDP framework for QUIC.</title>
<updated>2022-04-20T12:01:17+00:00</updated>
<author>
<name>Roman Arutyunyan</name>
<email>arut@nginx.com</email>
</author>
<published>2022-04-20T12:01:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=9d81ef744cdaacf1e52bcaec4224d375af5ba59b'/>
<id>9d81ef744cdaacf1e52bcaec4224d375af5ba59b</id>
<content type='text'>
Previously, QUIC used the existing UDP framework, which was created for UDP in
Stream.  However the way QUIC connections are created and looked up is different
from the way UDP connections in Stream are created and looked up.  Now these
two implementations are decoupled.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previously, QUIC used the existing UDP framework, which was created for UDP in
Stream.  However the way QUIC connections are created and looked up is different
from the way UDP connections in Stream are created and looked up.  Now these
two implementations are decoupled.
</pre>
</div>
</content>
</entry>
<entry>
<title>HTTP/3: removed useless warning regarding OpenSSL library.</title>
<updated>2022-01-13T12:57:15+00:00</updated>
<author>
<name>Sergey Kandaurov</name>
<email>pluknet@nginx.com</email>
</author>
<published>2022-01-13T12:57:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=a7a3a8cc1778fee8597b34ce5265453ceda81b08'/>
<id>a7a3a8cc1778fee8597b34ce5265453ceda81b08</id>
<content type='text'>
After 0e6528551f26, it became impossible to run into this path.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
After 0e6528551f26, it became impossible to run into this path.
</pre>
</div>
</content>
</entry>
</feed>
