Http 为什么没有'；websocket协议的设计者是否使用WS作为方法而不是GET？

我想知道为什么websocket协议的设计者决定使用GET方法，而不是创建一个名为“WS”的新方法

因为很多框架都能够通过方法和url进行路由，所以这会非常酷。

---

是否有反对新方法的理由？

可能是为了保持与现有HTTP/1.1系统的兼容性

HTTP/1.0仅支持3种方法：GET、POST和HEAD。 HTTP/1.1增加了PUT、DELETE、TRACE、OPTIONS、CONNECT和PATCH

添加WS方法将破坏与所有现有web系统的兼容性。

来自，第1.3节：

开场握手旨在与基于HTTP的握手兼容 服务器端软件和中介，使单个端口可以 由与该服务器和WebSocket对话的HTTP客户端使用 与该服务器对话的客户端

和1.8：

连接到HTTP共享的端口时 服务器（一种很可能发生的情况，其流量为 端口80和443），HTTP服务器将显示该连接 是具有升级优惠的常规GET请求。相对简单 仅使用一个IP地址和一台服务器进行所有流量的设置 对于单个主机名，这可能为系统提供了一种实用的方法 基于要部署的WebSocket协议

这只需要很少或不需要对web服务器本身进行配置，因为支持它的编程语言可以轻松地进行扩展，以理解和执行到WebSocket的通道升级。引入新的请求方法需要HTTP服务器理解此方法

如果你真的对为什么感兴趣，请随意搜索/阅读邮件列表。我认为处理这个问题的讨论题为“关于WEBSOCKET与现有方法（是关于GET与OPTIONS与new method的民意测验）”

---

这是一个巨大的阅读，从头开始。在草案05中，

获取

，之后从未更改：

乔和我，作为主席，还没有看到从这次民意调查中出现任何重大共识；因此，我们建议在不改变方法的情况下继续推进即将发布的05版本， 保持GET作为握手的方法， 由于其在WebSocket中的行为，握手已在现场进行了大量测试 现在大家都知道它是好是坏

---

公平地说，HTTP/1.1系统要宽松得多，因为它们还应该知道RFC2518（WebDAV）以及PROPFIND、PROPPATCH、MKCOL、COPY、MOVE、LOCK和UNLOCK。是否有处理未知方法的标准行为？我认为不会有任何Web服务器会做一些完全不同于仅仅发送404或405响应的事情。。。对于客户端来说，这只意味着“连接失败”…HTTP/1.1是为方法扩展而设计的。