proxy_protocol_port variable should store the PROXY_PORT rather than CLIENT_PORT

[Maxim Dounin]

Hello!

On Sat, May 13, 2017 at 09:11:13PM +0200, Janusz M wrote:

> I'd expect to see the original request's port 80 or 443 in this variable
> rather than relatively useless (IMHO) CLIENT_PORT which looks like 51501.

The $proxy_protocol_port, much like $proxy_protocol_addr, reflects 
client port for the proxy protocol header.  It is to be used 
(again, much like $proxy_protocol_addr) to log original client's port, 
which is needed to trace a particular client.  It also can be used in 
X-Real-IP / X-Forwarded-For to pass the port to upstream servers.  
Quoting nginx 1.11.0 changes:

    *) Feature: the $proxy_protocol_port variable.

    *) Feature: the $realip_remote_port variable in the
       ngx_http_realip_module.

    *) Feature: the ngx_http_realip_module is now able to set the client
       port in addition to the address.

Hope this help to understand how it is expected to be used.

> A typical use case for this change would look like the following:
> 
> 1. nginx HTTP server is running behind Amazon Load Balancer in TCP mode
> with PROXY PROTOCOL enabled (can be any TCP load balancer with proxy
> protocol on, useful for websockets for example)
> 2. nginx has the proxy_protocol turned on
> 3. we (or other apps, upstream servers) want to know what was the ORIGINAL
> port/protocol of the incoming request (eg. was it 80/HTTP or 443/HTTPS).
> 
> Currently it seems that it's impossible to get the request port/protocol
> value from nginx behind tcp load balancer. If nginx stored the PROXY_PORT
> instead of the CLIENT_PORT value in that (or another) variable it would be
> extremely easy for other apps to know the original port/protocol.
> 
> >>>
> server {
>   listen 80 proxy_protocol;
>   ...
>   proxy_set_header X-Forwarded-Port  $proxy_protocol_port; # 51505 instead
> of 443/80 !!
> }

This is a completely different use case.  Moreover, this use case 
can be easily avoided by forwarding connections to different 
ports within nginx.  And so, quoting your own words, "relatively 
useless".

> Please let me know if it's feasible or planned, or if we could actually
> read the original incoming request port in a different way

No, there are no plans to change current behaviour.

-- 
Maxim Dounin
http://nginx.org/