[Libwebsockets] recent changes breaking DomTerm
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
>>> 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
> in LWS_CALLBACK_HTTP_WRITEABLE.
> However, that doesn't fix the problem. Commenting out the
> "fixes" the problem. The problem seems to be related to sending
> which is 375373 bytes long. Could it be that the logic for
> 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
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