Home / user-129737

kbolino's questions

Martin Hope
kbolino
Asked: 2020-01-28 12:51:39 +0800 CST
  • 3

When using nginx as a reverse proxy to a group of servers in an upstream block, is there a variable that corresponds to the unresolved server name? For example, consider the following configuration:

http {
    upstream foo {
        server foo1.example.com:8080;
        server foo1.example.com:8081;
        server foo2.example.com:8080;
        server foo2.example.com:8081;
    }
    server {
        server_name foo.example.com;
        location / {
            proxy_pass http://foo;
        }
    }
}

Let foo.example.com, foo1.example.com, and foo2.example.com be defined names that resolve to 192.0.2.1, 192.0.2.2, and 192.0.2.3 respectively.

Suppose a request comes in for foo.example.com and nginx decides to choose foo2.example.com port 8080 as the upstream server and the request succeeds. Then, to my knowledge, these will be the values of some relevant variables:

  • $host = foo.example.com
  • $proxy_host = foo
  • $upstream_addr = 192.0.2.3:8080 (*)

However, none of these match the value given in the configuration for the upstream server. So, more specifically, my question is: which variable, if any, will have the value of foo2.example.com:8080 in this case?

To avoid the X-Y problem, these are the things I'm trying to accomplish:

  1. to log the upstream server by hostname rather than by IP address, since resolved IP address may be temporary or may not support 1:1 reverse lookup
  2. to map the upstream server to another piece of information that's more useful, also for logging purposes
  3. to configure hostname verification (e.g., via proxy_ssl_name) for upstream SSL when the servers don't share the same certificate (this might warrant a question of its own, but it's not the only use case)

(*) = The variable $upstream_addr does not seem to be available at all stages of the request, e.g. adding proxy_set_header Upstream-Addr $upstream_addr; to the location block seems to have no effect, implying the variable is empty

nginx
Martin Hope
kbolino
Asked: 2019-08-04 07:14:02 +0800 CST
  • 1

RFC 7540, § 9.1.1 states that

Connections [...] MAY be reused for requests with multiple different URI authority components [...] as long as the origin server is authoritative [...].

So, for example, if the same origin server can serve foo.example.com and bar.example.com then the client may reuse a connection to issue requests to both destinations. When that's not desired, the same section says

A server that does not wish clients to reuse connections can indicate that it is not authoritative for a request by sending a 421 (Misdirected Request) status code in response to the request [...].

This can arise in some unexpected situations, such as when virtual servers are used and their TLS configuration differs but they share a certificate using wildcards or subject alternative names.

Unfortunately, the end result is one or more extra round trips: the client optimistically reuses a connection, the server rejects the request, and then the client has to open a new connection and try again. In the worst case, this can be as bad as or perhaps even worse than just using HTTP/1.1 connections without reuse. It seems to get especially bad when there are many different destinations shared by the same origin server and sought by the same client, as each time a new connection is opened in response to a 421, the client still feels it can reuse that connection, and so the 421s can happen almost as often as useful responses.

Assuming the underlying problem is intractable, or at least the conditions under which a 421 response is sent are beyond the control of a server administrator, but the fact that it will happen is known, is there a way to inform clients in advance not to reuse connections across domains? This still leaves the primary benefit of HTTP/2 connection reuse, namely that multiple requests to the same domain can be multiplexed on a single connection, while also avoiding foreseeable 421 responses.

nginx