On 25/07/15 01:03, Daniel Stenberg wrote:
> If you insist on using libcurl for this, then I think that is at least
> a way you _can_ do it.
Yes, the benefit of using curl in this case, only to establish the
connection, is really small. That's why I tried to find/implement a
solution were the functionality of libcurl could be used for more than that.
> I haven't fully looked through the code path for this approach but it
> seems reasonable. And even if you made it work, it's not really a
> documented way to do it and we don't test for it so it would be a
> rather fragile method that could break in a future release.
I agree, this would be more a hack than a nice solution. If we go this
direction I think there should be a documented way to detach the
easy-handle from the multi-handle, without severing the underling
connection. After that the easy-handle could be freely used with
curl_easy_send() und _recv().
An Idea that comes to my mind would be to add a curl_easy_option that
let curl do the HTTP header send/receive part and then yields the
control to the application, similarly to CURLOPT_CONNECT_ONLY.
> It'd need to be more than that (like for example we always need to
> wait for the socket to be BOTH readable and writable since we don't
> know the protocol and that seems like a hard nut to crack or you need
> to signal that somehow)
I don't understand. Isn't it good enough to have the the KEEP_RECV/SEND
flags set? The sending is controlled by the READFUNCTION that could
return READFUNC_PAUSE if no data has to be sent. And the WRITEFUNCTION
is just called if there is data available from the server. This is
really low level, all the websocket protocol and framing stuff has to be
implemented in the application itself.
> and I'm also interested in how you imagine the API for
> enabling/controlling this. I'm slightly scared that allowing this is
> the first step on a slippery slope and that we will soon find out that
> it isn't enough to do good websockets anyway unless we also do
> something else that is more intrusive.
In this first approach I thought about it to be controlled by the
availability of the "Upgrade: websocket" header in the request (see new
patch). But maybe it would be better to enable it explicitly with a
config option. So far I also didn't consider yet to check the
correctness of the "Sec-WebSocket-Accept" header. But of course there
will be a minimum of checks that have to be performed before libcurl
switches to "websocket-mode".

After some more tinkering I also think after the protocol switch is
performed, the "conn->handler" should be switched to something simpler
that only receives and sends data back and forth on the socket (similiar
to telnet). This way the impact on existing code should be very limited.

I'm standing at crossroads. I'd be willing to put effort into this, but
I need guidance to know what could be done, and what would be accepted.
We are talking about quite different approaches. The first is more a
workaround to takeover the connection, whereas the other aims at a
"naturally" integrated solution.
Also my knowhow of the internals of libcurl might not be sufficient to
work out the solution in the needed quality by myself.
> And I'll again mention that we need test cases if we are to consider
> doing this.
I completely agree. I'd be willing to provide those too as far I can
manage, but might need some help with this too.

cheers, Frank

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html