> On 2 Jun 2020, at 07:58, PGNet Dev <pgnet....@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
