[Libwebsockets] Socket close during some HTTP gets

Andy Green andy at warmcat.com
Thu Jan 19 02:51:15 CET 2017

On 01/19/2017 09:41 AM, Michael Behrns-Miller wrote:
> Thanks Andy.
> I did grab your latest code, my issue persists.  When i trace into the
> handling, I find that in service.c ln ~553 :spin_chunks label,
> wsi->chunked is 1.  I then have to catch my chunked http packets in

It's possible the server you're talking to is just sending stuff with 
Content-encoding: chunked

CGIs tend to do it because they have no idea about the total length the 
script will gente but want to send stuff as it becomes available.

> LWS_CALLBACK_RECEIVE_CLIENT_HTTP_READ.  I'm afraid that I have not
> separated the wsi data of my websockets and http properly, and the wss
> chunked flag is set for my http traffic, maybe?
If you increase the logging to eg 63, you should see the http headers... 
check and see if it is supposed to be chunked first... I assume it is.

ws doesn't use HTTP chunked encoding... it's more likely your HTTP 
server actually is sending chunked.

What happens if you use the test client, eg

$ libwebsockets-test-client http://warmcat.com

will dump the HTML... does your server sending chunked kill it?  If so 
can I try it from here?


> On Wed, Jan 18, 2017 at 8:34 PM, Andy Green <andy at warmcat.com> wrote:
>> On 01/19/2017 06:25 AM, Michael Behrns-Miller wrote:
>>> Hello!
>>> I am working on interweaving an http get with a persistent wss client
>>> connection back to a server.  I am using one context and one protocol.
>>> lws always seems to go into "chunked' mode for the http get.  Some
>> What do we mean by, 'chunked'... there is literally HTTP chunked mode, which
>> has hex length headers before each chunk.  Or there is just "chunks" of data
>> coming rather than the whole thing at once.
>>> sites work, and others drop the socket connection before finishing the
>>> http get.
>>> To get it working, there is a lot to get right, and i am probably
>>> getting some part of it wrong.
>>> My strategy was to use a standard wss client connection (that went
>>> fine).  Then for the http get, I create a second
>>> lws_client_connect_info and wsi for it, and attach it to the context
>>> with lws_client_connect_via_info().
>> Sounds good...
>>> All my testing with local pages, big and small, seemed to work fine.
>>> Other tests (in this case a simple google query) gave this -d15 level
>>> debugging and failed to COMPLETE:
>>> [2017/01/18 16:42:09:3646] WARN: LWS_CALLBACK_RECEIVE_CLIENT_HTTP
>>> [2017/01/18 16:42:09:3646] WARN:
>>> [2017/01/18 16:42:09:3646] WARN: HTTP_READ of 365 bytes begins:
>>> on(a){try{var b=docu
>>> [2017/01/18 16:42:09:3646] WARN: HTTP_READ of 365 bytes ends :
>>> /(^|\\?|&)ei=/.test(
>>> [2017/01/18 16:42:09:3646] WARN: LWS_CALLBACK_RECEIVE_CLIENT_HTTP
>>> [2017/01/18 16:42:09:3646] INFO: lws_close_free_wsi: real
>>> just_kill_connection: 0x5555557dfe90 (sockfd 7)
>>> [2017/01/18 16:42:09:3646] INFO: remove_wsi_socket_from_fds: removing
>>> same prot wsi 0x5555557dfe90
>>> [2017/01/18 16:42:09:3646] INFO: remove_wsi_socket_from_fds:
>>> wsi=0x5555557dfe90, sock=7, fds pos=2, end guy pos=3, endfd=0
>>> [2017/01/18 16:42:09:3647] INFO: lws_header_table_detach: wsi
>>> 0x5555557dfe90: ah (nil) (tsi=0, count = 0)
>>> Some of the http gets do not log any errors, but never finish.  In
>>> debugging the code, I usually find that the call is perceived as
>>> chunked for some reason, and I guess the final chunked marker is never
>>> hit.
>>> Sorry Andy, that's a small bit of the picture I know.  Any advice?
>>> Even if it is just something to try.  Appreciate it.
>> Make sure you're using latest master lws first I think.  I fixed some bugs
>> around client HTTP last week.
>> There's nothing wrong with the overall approach you can have any mixture of
>> client connections as much as you like.
>> -Andy
>>> Michael
>>> _______________________________________________
>>> Libwebsockets mailing list
>>> Libwebsockets at ml.libwebsockets.org
>>> https://libwebsockets.org/mailman/listinfo/libwebsockets

More information about the Libwebsockets mailing list