<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hi<br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On 6 Apr 2024, at 12:32 AM, Sergey Kandaurov <pluknet@nginx.com> wrote:</div><br class="Apple-interchange-newline"><div><div># HG changeset patch<br># User Sergey Kandaurov <pluknet@nginx.com><br># Date 1712349104 -14400<br># Sat Apr 06 00:31:44 2024 +0400<br># Node ID 5fe21225ab3105aeea5e381a5d39ec1d3cfc04e6<br># Parent 47df39ea9e21c4359e0ca96dcc452f2bc8a82c44<br>Detecting duplicate addresses in listen among different modules.<br><br>This is used to gracefully reject the following configurations during<br>syntax checking with a "duplicate ... address and port pair" error:<br><br> http {<br> server {<br> listen 127.0.0.1:8080;<br> ...<br> }<br> }<br><br> stream {<br> server {<br> listen 127.0.0.1:8080;<br> ...<br> }<br> }<br><br>Also for wildcard addresses:<br><br> stream {<br> server {<br> listen 8080;<br> ...<br> }<br> }<br><br> mail {<br> server {<br> listen 8080;<br> ...<br> }<br> }<br><br>Notably, this won't catch mixed wildcard and non-wildcard addresses as<br>follows, where http server block with a specific address never accepts<br>new connections. </div></div></blockquote><div><br></div><div>Not sure what you mean mean by 'never accepts', but new connections surely</div><div>will be accepted by this server, just not directly. You probably mean there's</div><div>no designated listen socket for that address.</div><br><blockquote type="cite"><div><div> The reason is that http will end up listening on the<br>wildcard address, and stream is configured to listen on the specific<br>address, which is technically a valid case.<br><br> http {<br> server {<br> listen 127.0.0.1:8080;<br> ...<br> }<br><br> server {<br> listen 8080;<br> ...<br> }<br> }<br><br> stream {<br> server {<br> listen 127.0.0.1:8080;<br> ...<br> }<br> }<br><br>diff --git a/src/core/ngx_connection.c b/src/core/ngx_connection.c<br>--- a/src/core/ngx_connection.c<br>+++ b/src/core/ngx_connection.c<br>@@ -21,10 +21,27 @@ ngx_create_listening(ngx_conf_t *cf, str<br> socklen_t socklen)<br> {<br> size_t len;<br>+ ngx_uint_t i;<br> ngx_listening_t *ls;<br> struct sockaddr *sa;<br> u_char text[NGX_SOCKADDR_STRLEN];<br><br>+ ls = cf->cycle->listening.elts;<br>+ for (i = 0; i < cf->cycle->listening.nelts; i++) {<br>+<br>+ if (ngx_cmp_sockaddr(ls[i].sockaddr, ls[i].socklen,<br>+ sockaddr, socklen, 1)<br>+ == NGX_DECLINED)<br>+ {<br>+ continue;<br>+ }<br>+<br>+ ngx_conf_log_error(NGX_LOG_EMERG, cf, 0,<br>+ "duplicate \"%V\" address and port pair",<br>+ &ls[i].addr_text);<br>+ return NULL;<br>+ }<br>+<br> ls = ngx_array_push(&cf->cycle->listening);<br> if (ls == NULL) {<br> return NULL;<br>_______________________________________________<br>nginx-devel mailing list<br>nginx-devel@nginx.org<br>https://mailman.nginx.org/mailman/listinfo/nginx-devel<br></div></div></blockquote><br></div><div>I like the idea of fixing address collisions between modules. However, the patch does not fix the problem entirely and leaves</div><div>room for misconfigurations. IMHO we need to think how to properly fix this.</div><div><br></div><div>One way for fixing this is rejecting any overlapping listen addresses. We need to evaluate how likely it is that reasonable</div><div>configurations will be restricted by this. It doesn't seem likely to me.</div><br><div>
<div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div>----</div><div>Roman Arutyunyan</div><div>arut@nginx.com</div><div><br></div></div><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">
</div>
<br></body></html>