Perhaps it is helpful to clarify what I mean when I use the phrase "SNI is not required" or "SNI is required". The meaning of those phrases to me may not be the same as the meaning of those phrases to web developers or people at large commercial CDNs that are trying to influence "upgrades" of traditional internet protocols that were originally developed by people at universities.

What I mean by "SNI is not required" is that I can send an HTTP request over TLS without SNI and succesfully retrieve the resource I specified in the HTTP method line and Host header, e.g., if I send

GET /index.html HTTP/1.1
Host: example.com
Connection: close

without SNI and I receive index.html then, to me, "SNI is not required".

Whereas if I do not receive index.html unless I also send SNI, then, to me, "SNI is required". No one should interpret this phrase to indicate I do not understand the purpose behind SNI and why it exists. Nonetheless, I think the phrase is consistently misinterpreted.

In the 173.230.137.156 example I chose, I can still retrieve /5/doc/index.html from api.call-cc.org regardless of whether I send SNI. Yes, the api.call-cc.org FQDN name does have its own certificate. But I can send no SNI, I can send SNI "example.com" or I can send SNI "3e8.org" and in every case I can still retrieve /5/doc/index.html (using the certificate for 3e8.org for the public key, etc., the default certificate sent by the httpd at IP address 173.230.137.156). In this example, the operator of the httpd is not checking the SNI against the Host header.

Thus, to me, "SNI is not required" for this website. It does not matter whether there is one site hosted at the IP address, a handful of sites hosted or thousands of sites hosted. If I can get the media without sending SNI, then I do not send SNI. For anyone on-path who wants to know what sites internet users are visiting, it is none of their business what I have put in the Host header. That is why the Host header is encrypted. It is why TLS1.3 encrypts the certificate. And it is why ESNI/ECH encrypts the SNI as well. Not to mention it is why people _try_ to encrypt DNS. No one needs to know the sites a www user is visiting except the websites themselves.

The reader may wonder about certificate verification on the client side. For example, if a "tech" company-sponsored browser detects that the domain name specified in the Host header does not match a domain name specified in a certificate it may refuse to send the HTTP request. For many years, applications using SSL/TLS often failed to do certificate verification correctly or did not do it at all. Today, browsers sponsored by "tech" companies can do certificate verification. However those are not the only programs that can do it.

I use a localhost forward proxy to do certificate verification, not a web browser. This is because most HTTP requests I make are (a) noncommercial and (b) done with commandline utilities that do not support graphics and do not do certificate verification (nor SNI). "Noncommercial" here means free, recreational activities, and excludes things like banking, shopping and so forth. For commercial uses, I use a "modern" graphical browser.

In some ways, but not others, the phrase "SNI is required" is like the phrase "Javascript is required". I routinely make successful HTTP requests to sites whose web developers claim "Javascript is required". To initiate HTTP requests I use commandline utilities that do not support Javascript. Those requests are not over the wire, they are sent to a loopback address. Only the forward proxy sends HTTP requests and receives responses over the wire. To read HTML or consume other media types, I use a text-only browser or some other program. I have no trouble retrieving media from these sites. Neverthless, there are HN commenters who would still argue "Javascript is required".

A phrase can have different meanings to different people.