> On 2 Jun 2020, at 07:58, PGNet Dev <pgnet.dev@gmail.com> wrote:
>
> 2020/06/02 00:50:08 [info] 20166#20166: *3 client attempted to request the server name different from the one that was negotiated while reading client request headers, client: 127.0.0.1, server: test.example.net, request: "GET /app1 HTTP/1.1", host: "example.net"
>
> now, need to stare at this and try to figure out 'why?'

That means client provided TLS "server_name" extension (SNI),
then requested a different origin in the Host header.

In your case, the mangled name "test.example.net" (via SNI)
didn't match another mangled name "example.net" (in Host).

For the formal specification, see the last paragraph in RFC 6066, section-3:

If an application negotiates a server name using an application
protocol and then upgrades to TLS, and if a server_name extension is
sent, then the extension SHOULD contain the same name that was
negotiated in the application protocol. If the server_name is
established in the TLS session handshake, the client SHOULD NOT
attempt to request a different server name at the application layer.

421 is defined for such cases in HTTP.

--
Sergey Kandaurov

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx