<div dir="ltr">Hi Maxim,<div><br></div><div>First of all thanks for your quick reply. I read the nginx 1.11.0 and 1.11.4 release notes, thanks. Perhaps I wasn't as clear in my description as possible.</div><div><br></div><div>Please consider the following scenario:</div><div><br></div><div>* a client (user) with IP 185.12.12.12 makes an HTTPS request to the app and hits the load balancer</div><div>* load balancer forwards both HTTP and HTTPS requests to nginx server on port 80 (standard Amazon AWS setup)</div><div>* Proxy Protocol is turned on, load balancer adds the following line to the request:</div><div><br></div><div>  <span style="color:rgb(36,41,46);font-family:sfmono-regular,consolas,"liberation mono",menlo,courier,monospace;font-size:11.9px">PROXY TCP4 185.12.12.12 172.31.0.11 56324 443</span></div><div><br></div><div>* nginx with proxy_protocol on reads port 56324 to <span style="font-size:12.8px">$proxy_protocol_port.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div>The point is that with the current implementation, either nginx's behaviour or proxy protocol itself feels inconsistent.</div><div>You wrote:</div><div>"<span style="font-size:12.8px">The $proxy_protocol_port, much like $proxy_protocol_addr, reflects </span><span style="font-size:12.8px">client port for the proxy protocol header. "</span></div><div><span style="font-size:12.8px">but in fact, what we see in those variables is the client IP (public IP of the client's computer) and the load balancer port (not the client port).</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">What I meant by "relatively useless" is that I'd expect that in most cases people/apps care about the last value in the proxy protocol line, that is 443 in the above example.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">The code in </span><span style="color:rgb(36,41,46);font-family:sfmono-regular,consolas,"liberation mono",menlo,courier,monospace;font-size:11.9px;background-color:rgba(27,31,35,0.0470588)">src/core/ngx_proxy_</span><wbr style="color:rgb(36,41,46);font-family:sfmono-regular,consolas,"liberation mono",menlo,courier,monospace;font-size:11.9px"><span style="color:rgb(36,41,46);font-family:sfmono-regular,consolas,"liberation mono",menlo,courier,monospace;font-size:11.9px;background-color:rgba(27,31,35,0.0470588)">protocol.c </span>reads the first IP in that line and then skips to the first port number found. Don't you think that to read the 'client port' nginx should read the last port number in the line?</div><div><br></div><div>PS. I actually resolved my current issue by forwarding connections to different ports within nginx.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-05-15 15:17 GMT+02:00 Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<span class=""><br>
On Sat, May 13, 2017 at 09:11:13PM +0200, Janusz M wrote:<br>
<br>
> I'd expect to see the original request's port 80 or 443 in this variable<br>
> rather than relatively useless (IMHO) CLIENT_PORT which looks like 51501.<br>
<br>
</span>The $proxy_protocol_port, much like $proxy_protocol_addr, reflects<br>
client port for the proxy protocol header.  It is to be used<br>
(again, much like $proxy_protocol_addr) to log original client's port,<br>
which is needed to trace a particular client.  It also can be used in<br>
X-Real-IP / X-Forwarded-For to pass the port to upstream servers.<br>
Quoting nginx 1.11.0 changes:<br>
<br>
    *) Feature: the $proxy_protocol_port variable.<br>
<br>
    *) Feature: the $realip_remote_port variable in the<br>
       ngx_http_realip_module.<br>
<br>
    *) Feature: the ngx_http_realip_module is now able to set the client<br>
       port in addition to the address.<br>
<br>
Hope this help to understand how it is expected to be used.<br>
<span class=""><br>
> A typical use case for this change would look like the following:<br>
><br>
> 1. nginx HTTP server is running behind Amazon Load Balancer in TCP mode<br>
> with PROXY PROTOCOL enabled (can be any TCP load balancer with proxy<br>
> protocol on, useful for websockets for example)<br>
> 2. nginx has the proxy_protocol turned on<br>
> 3. we (or other apps, upstream servers) want to know what was the ORIGINAL<br>
> port/protocol of the incoming request (eg. was it 80/HTTP or 443/HTTPS).<br>
><br>
> Currently it seems that it's impossible to get the request port/protocol<br>
> value from nginx behind tcp load balancer. If nginx stored the PROXY_PORT<br>
> instead of the CLIENT_PORT value in that (or another) variable it would be<br>
> extremely easy for other apps to know the original port/protocol.<br>
><br>
> >>><br>
> server {<br>
>   listen 80 proxy_protocol;<br>
>   ...<br>
>   proxy_set_header X-Forwarded-Port  $proxy_protocol_port; # 51505 instead<br>
> of 443/80 !!<br>
> }<br>
<br>
</span>This is a completely different use case.  Moreover, this use case<br>
can be easily avoided by forwarding connections to different<br>
ports within nginx.  And so, quoting your own words, "relatively<br>
useless".<br>
<span class=""><br>
> Please let me know if it's feasible or planned, or if we could actually<br>
> read the original incoming request port in a different way<br>
<br>
</span>No, there are no plans to change current behaviour.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Maxim Dounin<br>
<a href="http://nginx.org/" rel="noreferrer" target="_blank">http://nginx.org/</a><br>
______________________________<wbr>_________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx-devel</a><br>
</font></span></blockquote></div><br></div>