[Libwebsockets] recent changes breaking DomTerm

Andy Green andy at warmcat.com
Wed Jan 24 03:49:04 CET 2018

On 24/01/18 10:39, Per Bothner wrote:
> 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?

Are you using latest master HEAD?  IIRC that had fixes after the 
original patch (it worked on http/2 I was testing with but missed a path 
on http/1).  Generally, https://libwebsockets.org is running recent 
master, so usually any obvious generic problem is found by me first.

Truncated output suppresses your code getting any WRITABLE callbacks for 
the duration.

If you're on HEAD, when it finds a write that seems to it to be 
back-to-back, it hexdumps it.  What is it hexdumping?


More information about the Libwebsockets mailing list