Open Nevon opened 3 years ago
The only reason I can think of is that this approach allows you to lazily query the server by its IP to avoid DNS resolution, without defining host and servername separately. Which sounds like a bit of a bad idea to me, tbh
SNI should be the conceptual equivalent of virtual hosting for HTTPS, so I imagine the reason could be for providing that behavior. I can't say if it's right or wrong, though.
https://github.com/nodejs/node/issues/22389 Found an issue that has been discussed since 2018.
What steps will reproduce the bug?
I'm not 100% sure that this is a bug, but it was surprising behavior that is different from any other http clients I've looked at (curl, python's httplib, nginx).
If you make an HTTPS request specifying a
host
header that is different from the requesthost
, theservername
used for SNI will be set to the value of thehost
header, unless thehost
header contains an IP address or you explicitly pass aservername
in the agent options.https://github.com/nodejs/node/blob/b0c0111b04201bf99fde0fe0616b9fdf1f33655d/lib/http.js#L1086-L1092
What is the expected behavior?
This was very surprising to me as the
host
header is part of the HTTP layer, and theservername
belongs to the TLS layer, and I have never seen a client behave this way. I would have expected thehost
(not thehost
header) to be used as the defaultservername
.For example using curl:
As you can see, the certificate is accepted:
If we do the same thing in Node, the certificate will be rejected as the certificate host name does not match the server name that we send:
This will result in
[ERR_TLS_CERT_ALTNAME_INVALID]: Hostname/IP does not match certificate's altnames
.Changing this so that the
host
is used as the defaultservername
instead of thehost
header is a small and simple change, but my question would be if this is done intentionally, and if so, why?Additional information