[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?

-Andy




More information about the Libwebsockets mailing list