Serving bigger files in HTTPS (HTTP2)

[Somritag]

Hi Andy,

What will be the best way to handle a bigger file (say appx. <170kb) is getting served from the callback while parallelly other streams/files are also getting served. Are there any example where such scenario is handled.

[lws-team]

If it's being handled by a mount / default http handler it will be sent in pieces asynchronously without having to do anything special.

There are no examples because it's a normal default serving situation for lws, eg, visiting https://libwebsockets.org/git/libwebsockets is an example of lws serving this kind of situation.

If there are problems doing it on esp32, you will have to look at the logs to find out what is going wrong.

[Somritag]

We are using on FREERTOS on stm32 , we are facing challenge for serving larger file , while one file takes more than 30 secs to load completely and we hav configured both websocket and webserver configured on same port. If only webserver is running we observe no challenge in serving pages concurrently.

[lws-team]

"websocket and webserver" on different ports is OK?

Chrome and ffox act the same?

What version of lws is it?

[Somritag]

Websocket(7681) and webserver(443)on different port is OK. I see all the pages getting served in 443 both in firefox and chrome.

Above snippet is how i am setting both websocket and webserver.

But errors are different wen both are on same port in chrome(connection_closed) vs firefox (Binding_error).

Libwebsocket 4.3.2 version

[lws-team]

Does it help to use main branch rather than an old version?

[Somritag]

As we have already ported 4.3.2 for For FREERTOS, and using IAR.. I see there are many changes to be done if we need to consider to upgrade to main branch. Are there any significant changes in the latest, which may help us in this scenario where WEBSERVER and WEBSOCKET on same port will work without connection getting closed ?

[Somritag]

If it's being handled by a mount / default http handler it will be sent in pieces asynchronously without having to do anything special.

There are no examples because it's a normal default serving situation for lws, eg, visiting https://libwebsockets.org/git/libwebsockets is an example of lws serving this kind of situation.

If there are problems doing it on esp32, you will have to look at the logs to find out what is going wrong.

It's getting handled in our own callback handler for serving files within LWS_HTTP_CALLBACK, and the final return type is lws_callback_http_dummy(wsi, reason, user, in, len);

[lws-team]

There should be a patch on lws that adapts it for your platform. It's never going to be a one-off thing and then you live forever at 4.3.2, this is not how software works, and it is not how support works either. It doesn't help you or me if you keep banging your head on the situation at an immutable May 2022 tag forever when maybe things fixed on v4.3-stable or main subsequently. Instead, you should recover your "platform patch" using git to capture your changes against unchanged 4.3.2 and then you can use this as the basis for the changes needed on main. Some of your changes might make sense (others may need some adaptation) to go in lws directly meaning they will already be there on updates.

Another thing to keep in mind is that if you call it, lws_callback_http_dummy() is going to try to handle whatever situation it finds, look at how the dynamic serving works on the -dynamic example... LWS_CALLBACK_HTTP is handled there by the example code itself and since it doesn't need the dummy stuff, it finishes its work for that callback by simply returning 0.