Open babelouest opened 3 years ago
Thanks for commenting! I've been away from the internet for a few days.
For adding extensions for the CURLOPT_WS_CONNECT_ONLY
option, I envisioned that the application would set the HTTP header Sec-WebSocket-Extensions
or Sec-WebSocket-Protocol
with the right values to negotiate the extension with the server. Since the socket is handed off to the app, I expected the app to deal with framing & any extensions.
I didn't have time to get the more full fledged approach document started. In this case, curl handles framing, validation, extensions, etc. Based on most of your post, I think this document will be where most of the extension logic will go.
Thanks for your feedback,
That's ok, the protocol and extensions can be handled by the application. It would make the implementation easier.
Nevertheless, since libcurl implements compression encoding, libcurl websocket could also implement permessage-deflate extension, at least with no extension parameter. What do you think?
I'm getting hung up on how to handle future extensions and that extensions can fundamentally alter how the websocket protocol works. Specifically things like framing being altered by extensions like deflate and the ordering of the extensions mattering appears to introduce a broad space to deal with.
I posted a start on the curl_multi ideas I have. I didn't include any extension details simply because I'm not sure how I like what I wrote yet & need to switch onto some other tasks.
In addition to
CURLOPT_WS_CONNECT_ONLY
, curl websocket should allow the client to specify one or more subprotocols and one or more extensions, something likeCURLOPT_WS_SUBPROTOCOL
andCURLOPT_WS_EXTENSION
.In addition, curl websocket should natively implement permessage-deflate extension natively with a dedicated option, like
CURLOPT_WS_EXTENSION_PERMESSAGE_DEFLATE
, and sub options to set the extension parameters: