Two libcurl-compat deviations in the new WebSocket FFI (from the adversarial review of the #139 implementation):
-
curl_ws_recv never returns CURLE_AGAIN. libcurl performs a non-blocking read and returns CURLE_AGAIN when no data is buffered; urlx blocks until a frame chunk arrives or the connection closes. Apps that poll with the documented `while(curl_ws_recv(...) == CURLE_AGAIN)` pattern still work (they just block inside the call), but apps multiplexing over their own event loop will stall. A proper fix needs a cancel-safe buffered frame decoder so a poll can be abandoned mid-header without losing bytes.
-
curl_ws_meta returns NULL in the write-callback context. libcurl documents curl_ws_meta for use inside the write callback during a callback-mode ws transfer (per-frame metadata). urlx's callback-mode transfer buffers the body and has no per-frame callback dispatch, so curl_ws_meta only works for connect-only mode receives.
Both are documented in the function docs; this issue tracks closing the gap.
Two libcurl-compat deviations in the new WebSocket FFI (from the adversarial review of the #139 implementation):
curl_ws_recv never returns CURLE_AGAIN. libcurl performs a non-blocking read and returns CURLE_AGAIN when no data is buffered; urlx blocks until a frame chunk arrives or the connection closes. Apps that poll with the documented `while(curl_ws_recv(...) == CURLE_AGAIN)` pattern still work (they just block inside the call), but apps multiplexing over their own event loop will stall. A proper fix needs a cancel-safe buffered frame decoder so a poll can be abandoned mid-header without losing bytes.
curl_ws_meta returns NULL in the write-callback context. libcurl documents curl_ws_meta for use inside the write callback during a callback-mode ws transfer (per-frame metadata). urlx's callback-mode transfer buffers the body and has no per-frame callback dispatch, so curl_ws_meta only works for connect-only mode receives.
Both are documented in the function docs; this issue tracks closing the gap.