A WebSocket Primer • Hacker News Board

Re: A WebSocket Primer

#21

Post by tec27 » Tue, Dec 17, 2013, 7:33 AM UTC

general_failure wrote: post #14

Does anyone know the purpose of Sec-WebSocket-Key and the associated Accept? I know the hashing stuff ( https://en.wikipedia.org/wiki/WebSocket ) but I don't understand why it exists.

It's there to help guarantee that the server the browser is connecting to actually understands websockets and isn't being "tricked" into opening a connection through clever request formulation. With that guarantee in place, browsers can trust servers to properly check for and limit cross-domain requests and the like and not need to use something like CORS to negotiate that stuff.

Re: A WebSocket Primer

#22

Post by tlb » Tue, Dec 17, 2013, 8:32 AM UTC

gwu78 wrote: post #19

Is there a commandline http client that can negotiate WebSockets? If so, I might be tempted to experiment.

Libwebsockets contains a simple command line client and server:

http://libwebsockets.org/

Re: A WebSocket Primer

#23

Post by dspillett » Tue, Dec 17, 2013, 10:25 AM UTC

yogo wrote: post #11

rch wrote: post #5

Earlier quoted context omitted.

Agreed. Both approaches have their place, but I see SSE getting overlooked too often.

I'm not 100% up to speed on SSE but since there is no way to "push" to a client isn't it just some form of polling at the end of the day? It's also not supported by IE yet: http://caniuse.com/eventsource Compare with http://caniuse.com/websockets

> isn't it just some form of polling at the end of the day?

Probably long-poll, a single connection from client to server kept alive with the occasional byte sent one way which sends the message and disconnects when there is something to send (the disconnect, requiring a new request from the client is because some clients won't process what has been sent immediately unless the connection is closed).

I once wrote a messaging client that operated this way. It is efficient in terms of bandwidth use and client footprint, though if you are using a process based we server it can be quite inefficient there (an event driven service on few processes/threads is far more efficient for handling many long-lived low-activity connections).

Re: A WebSocket Primer

#24

Post by general_failure » Tue, Dec 17, 2013, 3:38 PM UTC

tec27 wrote: post #21

general_failure wrote: post #14

Does anyone know the purpose of Sec-WebSocket-Key and the associated Accept? I know the hashing stuff ( https://en.wikipedia.org/wiki/WebSocket ) but I don't understand why it exists.

It's there to help guarantee that the server the browser is connecting to actually understands websockets and isn't being "tricked" into opening a connection through clever request formulation. With that guarantee in place, browsers can trust servers to properly check for and limit cross-domain requests and the like and not need to use something like CORS to negotiate that stuff.

Why not skip all the hashing stuff? Why not just have Sec-Key: 'secret' and expect a reply with Sec-Accept: 'secret'. (where secret is hardcoded constant)