libwebsockets handshake message was revised?

I upgraded libwebsockets today

This message:

1758003160973 HTTP/1.1 101 Switching Protocols Date: Tue, 16 Sep 2025 06:12:40 GMT Content-Type: application/json Connection: upgrade upgrade: websocket sec-websocket-accept: 5BJq6ihh1sc1WJpKs342nZb09YA= x-mbx-used-weight-1m: 5 x-response-time: 0ms

was received in event loop event LWS_CALLBACK_CLIENT_RECEIVE

which was not in this event for old version. Is there any neccessary reason to revise it?

could you let me know how to make it disappear in LWS_CALLBACK_CLIENT_RECEIVE

I am very latency-sensitive in event LWS_CALLBACK_CLIENT_RECEIVE, to do if every time may add the latency.

Thanks

Sep 16 '25 06:09 bethebest0622

and one more thing seems changed

the event_loop function's 4th argument and 5th argument, the void* and size_t

could you provide the change log, how can it make it compatible with old version?

Sep 16 '25 07:09 bethebest0622

I'm afraid in neither case do I understand what you're describing. The stuff about 'Switching Protocols' is a log? What does it mean to 'receive' this in the callback? As callback rx data?

'event_loop function' ... where do I find this?

If you do the work on lws, I'm sure we should take care about your convenience. But naturally if you don't, your convenience doesn't figure in anyone's calculations.

Sep 16 '25 08:09 lws-team

sorry for the bad description;

There is a callback function in lws. it looks like:

int event_cb(struct lws *wsi, enum lws_callback_reasons reason, void *user, void *in, size_t len) {
  switch (reason) {
    case LWS_CALLBACK_CLIENT_RECEIVE: {
        // handle the message from server side
        // Receive message: "1758003160973 HTTP/1.1 101 Switching Protocols Date ...." here, which is never happend in old libwebsockets version
    }
    default:{}
  }
}

In the old version, I never receive the above message in the code case LWS_CALLBACK_CLIENT_RECEIVE.

but after upgrading(git pull),

I got this from the code, which makes my old code didn't work.

also, i found the void * in and size_t len seems changed.

I want to know how can I make the code work on new version(after git pull).

Sep 16 '25 08:09 bethebest0622

Well, all of the args depend on the reason. And when there is information provided with in / len, only len bytes of it are valid. At &in[len] and past that, anything could appear. Since you don't mention len, I guess you are just looking at garbage past len bytes. If you stop doing that, I am guessing this is a lot less confusing.

Sep 16 '25 12:09 lws-team

Well, all of the args depend on the reason. And when there is information provided with in / len, only len bytes of it are valid. At &in[len] and past that, anything could appear. Since you don't mention len, I guess you are just looking at garbage past len bytes. If you stop doing that, I am guessing this is a lot less confusing.

I think it was not caused by the garbage bytes.

In my case, I have this function for event loop:

int event_cb(struct lws *wsi, enum lws_callback_reasons reason, void *user, void *in, size_t len)

I received this for void * in, and the len is 4092 in event LWS_CALLBACK_CLIENT_RECEIVE.

It seems the server side message was cut off the tail (the actual len is more than 4092). I confirmed the rx_buffer_size is enough(65535)

I do nothing on my code, the only difference is:

cut off tail used newest code(37686150755262571dc8956876521c1279db53a4)

the old-good version is 028d4dc2fb59dd90a6997eea04bcaed899adb0fe.

Besides, the newest code in main branch add this message in event LWS_CALLBACK_CLIENT_RECEIVE

1758787990651vHTTP/1.1 101 Switching Protocols
Date: Thu, 25 Sep 2025 08:13:10 GMT
Content-Type: application/json
Connection: upgrade
upgrade: websocket
sec-websocket-accept: VjV06WPqc0DxbWSPaeULHiQum0E=
x-mbx-used-weight-1m: 5
x-response-time: 0ms

which seems belong to event LWS_CALLBACK_CLIENT_ESTABLISHED before

could you have a look at this?

Thanks

Sep 25 '25 08:09 bethebest0622

I think it was not caused by the garbage bytes.

If you look beyond that valid part of heap or stack buffers, you'll see what used to be there. It's not surprising to see old message data composed there, since it was also composed on heap or stack and will sit there until something overwrites it.

The way lws deals with RX is that it calls back with whatever it read at that moment. So there is no relationship between the RX length and the message length, if the data is slow or memory is constrained it can fragment the RX into multiple goes until the message is done. So there is nothing strange about receiving part of the message, then subsequently the next part until it is complete.

Sep 25 '25 08:09 lws-team

ok, so this is the fragment of the message.

how can i know this is the fragment?

I think in the old version, only the whole message comes, the callback fuction will be called.

The new version add this for latecny consideration?

Sep 25 '25 08:09 bethebest0622

I think in the old version, only the whole message comes, the callback fuction will be called.

Well, I think people should be free to think what they like. Certainly it's tiring to argue with them.

However telling me, who wrote it, what you think the old version does, is not a good bet... you're wrong, it has always read into its main buffer and passed up whatever it found in front of itself at that moment. To understand where the chunk you happen to have read fits into the message, there are some apis

/**
 * lws_is_final_fragment() - tests if received fragment is last part of ws message
 *
 * \param wsi: lws connection
 */
LWS_VISIBLE LWS_EXTERN int
lws_is_final_fragment(struct lws *wsi);

/**
 * lws_is_first_fragment() - tests if received fragment is first part of ws message
 *
 * \param wsi: lws connection
 */
LWS_VISIBLE LWS_EXTERN int
lws_is_first_fragment(struct lws *wsi);

from lws-ws-state.h that will help you.

Sep 25 '25 08:09 lws-team

Well, I think people should be free to think what they like. Certainly it's tiring to argue with them.

I agreed, I apologized for the immature guess.

I seems understand the behind logic.

if the message is very large, the message will be splited into several parts.

i should append them until i get the final part

This is very reasonable, as the network handle the package with same logic.

Can I understand the new version problem as below?

**The old version append the fragment behind the libwebsockets library, so I dont need to handle the fragment append,

and the new version, increased the Custom flexibility, so the default behavior is to let user handle this in their own way?**

Sep 25 '25 09:09 bethebest0622

No, lws has never done fragment reassembly. In the extreme case it's impossible actually, ws supports fragments each of which can be much larger than any machine's RAM, and you can have any number of those fragments composing an "endless message".

But "endless messages" are quite useful, say you are streaming some huge live audio you don't know the size of, you might do GB of it. But you don't want to wait until the end f the audio show to present it all at once to the listener. You want to play what you have as it comes, on perhaps a very modest device. So lws leaves it up to you to decide if you need to reassemble it and present it as a single, contiguous "message". (lws also provides a stateful JSON decoder which is compatible with decoding what you have and continuing when more comes).

However if your network is fast, and lws has a large rx buffer (you can control the size in the context creation info .pt_serv_buf_size, the default actually depends on the platform ), and your messages fit in the rx buffer, then it might be able to read everything at once.

Sep 25 '25 09:09 lws-team

However if your network is fast, and lws has a large rx buffer (you can control the size in the context creation info .pt_serv_buf_size, the default actually depends on the platform ), and your messages fit in the rx buffer, then it might be able to read everything at once.

Yes, this is the problem, I set the rxbuffer size with 65536, it's absolutely enough for the json text message, I expected all the message was read at once.

Here is my context create function

lws_context * WsBase::create_context() {
  if (ctx_) EE("Create Lws Context Again\n");
  struct lws_context_creation_info info;
  memset(&info, 0, sizeof(info));

  info.port = CONTEXT_PORT_NO_LISTEN;
  info.fd_limit_per_thread = cfg_->exists("fd_num") ? cfg_->lookup("fd_num") : 20;

  // here rx_size is 65535 !!!
  struct lws_protocols protocols[] = {{"ws", &event_cb, 4096, 65535, 1, NULL}, LWS_PROTOCOL_LIST_TERM};
  info.protocols = protocols;
  info.gid = -1; 
  info.uid = -1; 
  info.timeout_secs = 0;
  // lws_set_log_level(LLL_ERR | LLL_WARN | LLL_NOTICE | LLL_DEBUG, NULL);

  info.options |= LWS_SERVER_OPTION_DO_SSL_GLOBAL_INIT;
  return lws_create_context(&info);
}

I expect this will not be fragment.

Is libwebsockets setting method updated?

Sep 25 '25 09:09 bethebest0622

I expected all the message was read at once.

It may not all have come at the time we start reading it. It will wake the event loop when the first packet comes.

(you can control the size in the context creation info .pt_serv_buf_size, the default actually depends on the platform)

You need to set this above as well.

Sep 25 '25 09:09 lws-team