That would explain my confused comment in #10347. That failing assert may have been pointing to this.

I don't think that is correct. The frame struct contains metadata about this frame, not about pending data in general as we provide a pointer to that struct with curl_ws_meta(). frame.bytesleft should therefor not have a larger value than number of bytes left that belongs to this frame.

Clearly, I haven't puzzled my way through the websockets code sufficiently yet...

BTW, this really shows we should improve the test suite for WebSocket. It's too "bare bones" right now.

@bagder What is a frame?
Suppose the server sent 20K message as a single frame, with FIN bit set. libcurl receives first 16K, processes it, then receives final 4K, processes it. But both 16K and 4K fragments are the same frame from my point of view. So it is naturally that bytesLeft has the value of 20K (not 4K which it is in current code).

I mean frame as in a WebSocket frame as defined in RFC 6455.

both 16K and 4K fragments are the same frame from my point of view

If they are indeed a single 20K WebSocket frame, then the two data pieces are indeed just two parts of the same frame. The libcurl API can provide the frame to the application in two parts though.

it is naturally that bytesLeft has the value of 20K (not 4K which it is in current code).

Bytesleft should then be (20K - size of the current fragment), yes. Number of bytes left of this frame after this piece has been delivered. If this is 16K and the entire frame is 20K, then there is 4K left.

Suppose I pass 1K buffer to curl_ws_recv. If Bytesleft is initally 4K, then I will get 4K data in 4 curl_ws_recv calls, bytesLeft will decreased to 0 (4-1-1-1-1) and game over. If I call curl_ws_recv 5th time for some reason then new 4K fragment will be read, accidently decoded and bytesLeft will have random value.

Sorry, I don't follow. I understand that there is an issue here, I just think that the fix needs to be different than what you proposed above.

If I call curl_ws_recv 5th time for some reason then new 4K fragment will be read, accidently decoded and bytesLeft will have random value.

Why? When curl_ws_recv is called with bytesleft == 0, then does it not reach this code block?

Why? When curl_ws_recv is called with bytesleft == 0, then does it not reach this code block?

Oops sorry you're right, in the case of bytesleft == 0 ws_decode block is not called, datalen is assigned to 0 and we get an endless loop.

I just think that the fix needs to be different than what you proposed above.

I believe that my bad English does not allow me to convince you. :-)

then the two data pieces are indeed just two parts of the same frame.

Hence wsp->frame.bytesleft should contain bytes left in the frame to be delivered to a caller. Initially (right after ws_decode call) it is 20K (full frame size), 1K of these 20K are memcopied to the 1K user's buffer, at the same time bytesleft is reduced by 1K, so the user gets back 1K in *nread and 19K in meta.bytesleft after 1st curl_ws_recv call. Next call gets a user 1K in *nread and 18K in bytesleft and so on.

badger: Why? When curl_ws_recv is called with bytesleft == 0, then does it not reach this code block?

mikeduglas: Oops sorry you're right

Actually you aren't right, the condition is "!wsp->frame.bytesleft" so when bytesleft == 0 then the condition is true and the block is reached. But it makes little difference, in any case when bytesleft is initially set to 4K, the code fails.

By the way, in struct websocket (ws.h) there is a member oleft:

  curl_off_t oleft; /* outstanding number of payload bytes left from the
                       server */

which is never used. In my example that 4K should be assigned to this wsp->oleft.

The fix is bigger than what has been discussed here. I am working on it.