The websocket wire protocol only comes into effect after a successful handshake. The handshake involves a request to the endpoint by the client (typically a GET) and a response by the endpoint (101 switching protocols). As such websockets themselves do not concern themselves with headers and the other miscalnea of HTTP beyond the handshake protocol (which is tacked onto HTTP). CORS is also tacked onto HTTP, and so if you enforce CORS on http, this will automatically apply to the handshake of a websocket, which goes over HTTP. And so still no change is required to the websocket protocol. On Thu, Feb 5, 2015 at 2:41 PM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Thu, Feb 5, 2015 at 2:39 PM, Florian Bösch <pyalot@gmail.com> wrote: > > On Thu, Feb 5, 2015 at 2:35 PM, Anne van Kesteren <annevk@annevk.nl> > wrote: > >> Wouldn't that require the endpoint to support two protocols? That > >> sounds suboptimal. > > > > CORS and Websockets are two separate protocols which each work off and by > > themselves, there is no change required to either to make one work with > the > > other, and both adequately deal with non-implementation by the endpoint. > A > > webserver with support for CORS and Websockets already implements both > > protocols, and so no additional burden is imposed regardless. > > The protocols in question are HTTP and WebSocket... CORS is very much > unrelated to most of this. It's just the solution we have for HTTP at > the moment and WebSocket has something similar, just not for headers > and that is the problem. > > > -- > https://annevankesteren.nl/ >
Received on Thursday, 5 February 2015 13:46:26 UTC