Hello!
On Tue, Jun 02, 2020 at 01:01:18PM -0700, PGNet Dev wrote:
> On 6/2/20 12:34 PM, Maxim Dounin wrote:
> > The mis-match comes from trying to redefine the name in some parts
> > of the configuration but not others. Hope the above explanation
> > helps.
>
> I've reread your comment
>
> That is, the name you've written in the proxy_pass directive is
> the actual hostname, and it will be used in the Host header when
> creating requests to upstream server. And it is also used in the
> proxy_ssl_name, so it will be used during SSL handshake for SNI
> and certificate verification.
>
> It's not just "an upstream name". If you want it to be only an
> upstream name, you'll have to redefine at least proxy_ssl_name and
> "proxy_set_header Host". (Well, not really, since $proxy_host is
> also used at least in the proxy_cache_key, but this is probably
> not that important.)
>
> a bunch of times. Still can't grasp it clearly. Which is the source of the
> pebkac :-/
Read: if you want to use an internal upstream name in proxy_pass,
consider using _both_ "proxy_ssl_name" and "proxy_set_header
Host", for example:
proxy_pass https://test-upstream;
proxy_set_header Host test.example.com;
proxy_ssl_name test.example.com;
There are few other places where the hostname from the proxy_pass
directive is used, but the probably aren't that important.
> Otoh, simply _doing_
>
> Alternatively, you may want to use the real name, and define an
> upstream{} block with that name. This way you won't need to
> redefine anything.
>
> i.e., changing to EITHER
[...]
> now, in _either_ case, access to
>
> https://example.com/app1
> https://example.com/app1/
>
> _does_ return my 'test' app correctly
So everything is fine, as expected.
> i _do_ see in logs
>
> in case (2), a single error instance,
>
> 2020/06/02 12:51:11 [debug] 6140#6140: *3 reusable connection: 1
> 2020/06/02 12:51:11 [debug] 6140#6140: *3 http wait request
> handler
> 2020/06/02 12:51:11 [debug] 6140#6140: *3 malloc:
> 0000563CDA76DF10:1024
> 2020/06/02 12:51:11 [debug] 6140#6140: *3 SSL_read: 345
> 2020/06/02 12:51:11 [debug] 6140#6140: *3 SSL_read: -1
> ??? 2020/06/02 12:51:11 [debug] 6140#6140: *3 SSL_get_error: 2
> 2020/06/02 12:51:11 [debug] 6140#6140: *3 reusable connection: 0
> 2020/06/02 12:51:11 [debug] 6140#6140: *3 posix_memalign:
> 0000563CDA2963A0:4096 @16
> 2020/06/02 12:51:11 [debug] 6140#6140: *3 posix_memalign:
> 0000563CDA650060:4096 @16
>
> &
>
> in case (1), a double error instance
>
> 2020/06/02 12:53:46 [debug] 6267#6267: *6 SSL_read_early_data:
> 2, 0
> 2020/06/02 12:53:46 [debug] 6267#6267: *6 SSL_do_handshake: 1
> 2020/06/02 12:53:46 [debug] 6267#6267: *6 SSL: TLSv1.2, cipher:
> "ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA
> Enc=CHACHA20/POLY1305(256) Mac=AEAD"
> 2020/06/02 12:53:46 [debug] 6267#6267: *6 reusable connection: 1
> 2020/06/02 12:53:46 [debug] 6267#6267: *6 http wait request
> handler
> 2020/06/02 12:53:46 [debug] 6267#6267: *6 malloc:
> 0000563C0F2ADAB0:1024
> 2020/06/02 12:53:46 [debug] 6267#6267: *6 SSL_read: -1
> ??? 2020/06/02 12:53:46 [debug] 6267#6267: *6 SSL_get_error: 2
> 2020/06/02 12:53:46 [debug] 6267#6267: *6 free: 0000563C0F2ADAB0
> 2020/06/02 12:53:46 [debug] 6267#6267: *6 http wait request
> handler
> 2020/06/02 12:53:46 [debug] 6267#6267: *6 malloc:
> 0000563C0F2ADAB0:1024
> 2020/06/02 12:53:46 [debug] 6267#6267: *6 SSL_read: 339
> 2020/06/02 12:53:46 [debug] 6267#6267: *6 SSL_read: -1
> ??? 2020/06/02 12:53:46 [debug] 6267#6267: *6 SSL_get_error: 2
> 2020/06/02 12:53:46 [debug] 6267#6267: *6 reusable connection: 0
> 2020/06/02 12:53:46 [debug] 6267#6267: *6 posix_memalign:
> 0000563C0F18FA60:4096 @16
> 2020/06/02 12:53:46 [debug] 6267#6267: *6 posix_memalign:
> 0000563C0EDD4B10:4096 @16
> 2020/06/02 12:53:46 [debug] 6267#6267: *6 http process request
> line
>
>
> but that error doesn't seem to be fatal.
>
> any idea what's causing those^^ errors?
These aren't errors, these are debug messages. The
SSL_get_error() return code 2 means SSL_ERROR_WANT_READ, that is,
SSL_read() consumed all the data from the socket and needs more
data to read further. These messages are perfectly normal and
expected.
--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
