CODEWITHSUNDEEP
httpwebsocket
Van Coding
Van Coding

Reputation: 24534

why didn't the designers of the websocket protocol use WS as the method instead of GET?

I'm wondering why the designers of the websocket protocol decided to use the GET method instead of creating a new method called for example "WS"?

Since much frameworks are able to route by method and url, this would have been pretty cool. Are there reasons against a new method?

Upvotes: 4

Views: 137

Answers (2)

CodeCaster
CodeCaster

Reputation: 151604

From RFC 6455, section 1.3:

The opening handshake is intended to be compatible with HTTP-based server-side software and intermediaries, so that a single port can be used by both HTTP clients talking to that server and WebSocket clients talking to that server.

And 1.8:

When a connection is to be made to a port that is shared by an HTTP server (a situation that is quite likely to occur with traffic to ports 80 and 443), the connection will appear to the HTTP server to be a regular GET request with an Upgrade offer. In relatively simple setups with just one IP address and a single server for all traffic to a single hostname, this might allow a practical way for systems based on the WebSocket Protocol to be deployed.

This requires little or no configuration to the web server itself, as the programming language backing it can easily be extended to understand and execute an upgrade of a channel to WebSockets. Introducing a new request method would've required the HTTP server to understand this method.

If you're really interested in the why, feel free to search / read the http://www.ietf.org/mail-archive/web/hybi/ mailing lists. I think the discussion handling this is titled "On WEBSOCKET vs existing methods (was straw-poll on GET vs OPTIONS vs new method)".

It's a gigantic read, starting around here. In draft 05, GET was chosen and never changed afterwards:

Joe and I, as chairs, haven't seen emerging any significant consensus from this straw-poll; so we suggest to move forward with no change of method for the upcoming 05 version, keeping GET as method for the handshake, as its behavior in the WebSocket handshake has been largely tested in the field and it is now well know for better and worse.

Upvotes: 3

Szymon Smakolski
Szymon Smakolski

Reputation: 132

Probably to maintain compatibility with existing HTTP/1.1 systems.

HTTP/1.0 only supported 3 methods: GET, POST, and HEAD. HTTP/1.1 added PUT, DELETE, TRACE, OPTIONS, CONNECT, and PATCH.

Adding a WS method would break compatibility with all existing web systems.

Upvotes: 1

Related Questions