http: servername === false should disable SNI

[indutny]

There is no way to disable SNI extension when sending a request to HTTPS
server. Setting options.servername to a falsy value would make Node.js
core override it with either hostname or ip address.

This change introduces a way to disable SNI completely if this is
required for user's application. Setting options.servername to false
in https.request would disable overrides and thus disable the
extension.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[nodejs-github-bot]

Lite-CI: https://ci.nodejs.org/job/node-test-pull-request-lite-pipeline/3308

[indutny]

cc @nodejs/http @nodejs/crypto

[srl295]

LGTM. (though I did not have this use case, it is plausible and would have simplified my testing)

[indutny]

Thank you for review everyone!

[apapirovski]

LGTM but one nit re: documentation.

[apapirovski]

Boolean might be slightly misleading? It's really {string | false} since setting it to true won't do what one might expect...

[vsemozhetbyt]

Beware that false will be the only type case here and will baffle doc tools (tools/doc/type-parser.js will throw).

[indutny]

That was exactly my reasoning. We might want to use null as @bnoordhuis has suggested to fix this!

[bnoordhuis]

LGTM % nits others pointed out.

Observation: I don't think you can conclude from the test that no SNI extension is sent, just that the user's code doesn't set it explicitly. Maybe add a { SNICallback: cb } to the server's options object to verify?

Question: isn't null a better value than false for the opt-out when true doesn't work?

[indutny]

@bnoordhuis I think the test verifies it very well. The socket.servername is set to false only when there is no SNI present, AFAIK!

Is there a common practice for falsey values that we try to follow in core? In this PR's case - there are three possible types of values undefined, string, or null/false.

@vsemozhetbyt @apapirovski @srl295 @lpinca @BridgeAR may I ask y'all for an opinion on the topic?

[BridgeAR]

@indutny

Is there a common practice for falsey values that we try to follow in core

Not that I am aware of. Using undefined seems a bad option, since it's often handled as not existing. So a property with undefined as value would be considered not set. Using an empty string in this specific case might be an alternative but AFAIC only if there's no valid use case for that so far.

Using null is somewhat ambiguous in core. It's often ignored while we mostly become stricter with type checks and often do not accept null as alternative to undefined anymore. In this specific case I would consider it a good option to indicate the wish to disable the functionality.

I can not think of any API that only accepts false but not true, so that would be something new in core.

Thus, I personally would go with either an empty string or null while not blocking false.

[sam-github]

I agree that an empty string and/or null would be better than false.

https://tools.ietf.org/html/rfc6066#section-3 doesn't allow zero-length server names, so an empty string is not a valid value, and attempting to set one will error with SSL_R_SSL3_EXT_INVALID_SERVERNAME if a string of length zero is passed to SSL_set_tlsext_host_name().

[indutny]

Alright, updated the PR to use '' instead of false. PTAL @nodejs/collaborators

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/22749/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/22797/ ✅

[Trott]

Landed in 98e9de7