即使请求不是 HTTP/1.1，SSL 上是否也需要 Host：标头？
因此，如果客户端通过 SSL 连接并发送以下请求：
GET / HTTP/1.0
- 由于缺少 Host: 标头，Web 服务器是否应该抛出错误请求？
- Web 服务器是否应使用 HTTP/1.0 200 OK 响应进行响应？
（index.html 文件始终存在，因此对/，绝不会导致 403/404）
更新：
如果我在中禁用 SNI openssl s_client，则 apache 无需 Host: 标头即可工作。
为什么 SNI 开启时需要 Host: 标头？
答案1
根据标准，HTTP/1.0 请求不需要 Host，但在实践中通常仍需要此标头来决定在多域设置中提供哪些内容。但如果不存在此标头并且仍然清楚要提供哪些内容，则可以提供此内容而无需标头。请注意，这与 TLS 和 SNI 的使用无关。
答案2
为了回答更新中添加的问题部分，
为什么 SNI 开启时需要 Host: 标头？
“需要”是一个很强烈的词，但它有助于理解 SNI 和 HTTP 标头在两个不同的层上运行，因此服务于两个不同的目的。
SNI 是主要用于确定向客户端提供哪个证书。在具有多个虚拟主机的设置中，在解密有效负载之前，服务器必须向客户端提供证书。由于证书包含站点的名称（传统上是证书主体的通用名称，但最近是 X.509 扩展主体备用名称），因此提供错误的证书会导致客户端在向服务器发送 HTTP 请求之前拒绝连接。
而Host标题是主要用于确定要提供哪些资源。在行为良好的客户端中，这与 SNI 中的名称是多余的，但 HTTP/1.1 是在大约同一时间开发的SSL 3.0因此早在 TLS-SNI 扩展出现之前就存在了。事实上，正是 HTTP/1.1 和 SSL/TLS 的组合才首次发现了对 SNI 的需求。
值得注意的是，HTTP/2不是需要Host报头，但具有伪报头形式的功能等效性:authority。尽管那在大多数情况下，标头仍将与 TLS-SNI 重复，但始终包含它可以简化实现。
始终包含Host(或:authority) 标头也为 SSL 终止留下了可能性（尽管实际上，没有 TLS 的 HTTP/2 很少得到支持）。但是，不验证主机/授权机构是否与 TLS-SNI 中的名称匹配可能会在某些设置中打开安全漏洞。