You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are similar issues for client: #1548
And there is a minimal websocket server in master branch since commit e831308, including 11+ commits after.
For websocket, we should think about how libevent would offer websocket.
generate sec-websocket-key? requiers base64, used by client to generate, and server to validate.
generate sec-websocket-accept? requires sha1, used by client to validate, and server to generate.
handle websocket handshake? leave the sec-websocket-key / sec-websocket-accept for user code, or offer them in libevent?
IMO, libevent shouldn't offer base64 / sha1, user choose their own from mbedtls or openssl should be better.
parse websocket frame? use bufferevent_filter_new with BEV_NEED_MORE is easy.
support mask? and custom fin, rsv, op, ...?
build / make websocket frame?
support mask? and custom fin, rsv, op, ...?
should 64-bits payload be supported?
if it's less than 2**16, libevent / user code can buffer such a small frame.
otherwise, libevent / user code should remember the mask key in the frame lifecycle.
handle ping automatically?
support custom extension?
IMO, if libevent choose to offer websocket, both client and server should be offered.
And when extra components were added in libevent, we should consider the quality. I never forget the issue in stackoverflow:
the extra components such as the http and dns servers suffered from bad implementation quality and resultant security issues
The comments were issued on 2012, and updated on 2017, and I don't agree it after a simple review for the http component I'm using.
However, we should consider for the extra component in libevent.
The text was updated successfully, but these errors were encountered:
There are similar issues for client: #1548
And there is a minimal websocket server in master branch since commit e831308, including 11+ commits after.
For websocket, we should think about how libevent would offer websocket.
sec-websocket-key
? requiers base64, used by client to generate, and server to validate.sec-websocket-accept
? requires sha1, used by client to validate, and server to generate.sec-websocket-key
/sec-websocket-accept
for user code, or offer them in libevent?bufferevent_filter_new
withBEV_NEED_MORE
is easy.IMO, if libevent choose to offer websocket, both client and server should be offered.
And when extra components were added in libevent, we should consider the quality. I never forget the issue in stackoverflow:
The comments were issued on 2012, and updated on 2017, and I don't agree it after a simple review for the http component I'm using.
However, we should consider for the extra component in libevent.
The text was updated successfully, but these errors were encountered: