[Libwebsockets] recent changes breaking DomTerm

Per Bothner per at bothner.com
Wed Jan 24 03:39:33 CET 2018

Right now I'm looking at issue (3):

On 01/22/2018 11:43 PM, Andy Green wrote:
>> (3) DomTerm doesn't require LWS_WITH_ZIP_FOPS to be enabled.  Instead,
>> if you configure it --enable-compiled-in-resources then it serves the
>> needed JavaScript+CSS  directly from initialized static byte arrays.
>> This works fine [*] until we get to:
>>      commit 1da0197798c3c19e5b60dd0e47b1724f08ce56de
>>      Date:   Thu Dec 7 07:20:47 2017 +0800
>> which breaks the --enable-compiled-in-resources (non-zip-fops) version
>> as well.   So now I'm screwed.
> This patch adds logical checking for any possibility of back-to-back writes, with no return to the event loop inbetween, instead of just waiting for them to occur where the first one was a partial.  So this may be showing you problems related to that in your user code.

I think I found a bug in DomTerm in that it writes the data right
after the headers, in the same LWS_CALLBACK_HTTP call.  I changed
that to call lws_callback_on_writable, and write the actual response

However, that doesn't fix the problem.  Commenting out the wsi->could_have_pending
"fixes" the problem.  The problem seems to be related to sending "hlib/domterm-all.js"
which is 375373 bytes long.  Could it be that the logic for setting/clearing
could_have_pending doesn't doesn't work with truncated output?
	--Per Bothner
per at bothner.com   http://per.bothner.com/

More information about the Libwebsockets mailing list