[Libwebsockets] latest commit breaks DomTerm's http serving
andy at warmcat.com
Mon Oct 9 00:01:02 CEST 2017
On 10/09/2017 05:41 AM, Per Bothner wrote:
> On 10/08/2017 02:24 PM, Andy Green wrote:
>> On 10/09/2017 05:13 AM, Per Bothner wrote:
>>> The latest check-in to git at github.com:warmcat/libwebsockets.git
>>> breaks DomTerm. Specifically, it appears to be how resources
>>> using plain http are served out of a .jar file. More specifically,
>>> the files appears to be complete and non-garbled - but the wrong
>>> files are served. For example the browser will complain about syntax
>>> downloaded by the browser) it's one of the css files.
>>> Commit 44d824554aa0a1cf7e7a043cbf9b4ce584ece554 appears bad.
>>> The previous 7dca65320baf02d7fdf24a17f8dd0be08cb41008 is good.
>>> It's a fairly big changeset, so the problem is non-obvious.
>> How are the files being served in your app, it's via mounts or "by hand"?
> It's a mount point.
> See the mount_domterm_zip variable in
I checked an ESP32 app I have that serves files direct from zip, the
files are not mixed up with or without HTTP/2 using that commit.
Reviewing the h2 megapatch, it doesn't touch fops_zip.
If you have HTTP/2 turned off as is the default, it's really difficult
for lws to mix up streams... it's easier to imagine with HTTP/2 where
the streams share a network connection, but I have never seen it happen
here. So presumably the problem is related to picking the wrong file
out of the zip. Can you check?
More information about the Libwebsockets