HTTP升级机制的支持程度如何？

我一直在研究HTTP 1.1（RFC 2817）中的Upgrade header字段，碰巧读到了HTTP的wikipedia条目。该条声明如下：

然而，浏览器对升级头的支持几乎不存在，因此HTTPS仍然是建立安全HTTP连接的主要方法

---

我希望实现我的web服务，使其依赖于Upgrade header字段，以避免必须侦听两个套接字（一个用于HTTP，另一个用于HTTPS）。我无法在任何其他地方证实这一说法，这使我对这样做感到有些紧张。wikipedia中的上述说法是否近乎正确，或者是一个粗略的概括？

我更愿意将其全部放在http中，但目前的情况更倾向于服务器名称指示，因为它得到了广泛的支持。也很难表明您希望客户端使用url进行升级。因此，如果目标是虚拟主机，一种方法是TLS“服务器名称指示”。参见RFC3546或

我在维基百科的页面上研究过这个问题，实际上遇到了这个问题。我环顾四周，以下是我所能看到的浏览器支持情况：

• Chromium支持升级标头，例如
• Firefox不支持“升级：TLS”，尽管最近一次评论是在2010年发表的。我猜他们不会很快加入
• InternetExplorer10+可能会，因为它描述了如何使用升级连接到websocket服务器。也意味着IE10支持“升级：websocket”
• Safari 6+支持升级（请参阅）

对于所有受支持的浏览器，我只找到了使用“Upgrade:websocket”的例子，没有一个说升级到TLS会起作用。因此，总的答案是，在生产应用程序中依赖它是有风险的

---

服务器支持似乎更好；Apache从2.1开始就支持“升级：TLS”。

http使用端口80，https使用端口443是正常的-为什么要避免侦听两个端口？^正如thejh所说，而且，您可以在同一端口上同时使用SSL和非SSL，但更糟糕的是，IMHO.RFC2817的设计完全符合Wrikken的要求，并且有一个介绍，说明了这样做的理由。我不知道你为什么说它“更糟”。他想说同一端口上的SSL和非SSL比HTTP升级更糟。我的案例涉及实现HTTP服务器的自定义程序。如果启用了HTTPS，我决定直接重定向到HTTPS。“服务器名称指示”功能实际上与我最初试图完成的任务无关，也与HTTP升级机制无关。Chromium不支持“upgrade:TLS”，请参阅