[Libwebsockets] latest commit breaks DomTerm's http serving

Andy Green 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
>>> errors in a JavaScript file, and when I look at the source (as
>>> 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
> https://github.com/PerBothner/DomTerm/blob/master/lws-term/server.c

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 mailing list