[Libwebsockets] recent changes breaking DomTerm
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
>> 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 at bothner.com http://per.bothner.com/
More information about the Libwebsockets