[Libwebsockets] Socket close during some HTTP gets

Michael Behrns-Miller moodboom at gmail.com
Thu Jan 19 02:45:18 CET 2017


Oh, also of note: If I hit breakpoints or put in delays, I often don't
see the problem, but not consistently.

On Wed, Jan 18, 2017 at 8:41 PM, Michael Behrns-Miller
<moodboom at gmail.com> 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
> 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?
>
> 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:
>>> LWS_CALLBACK_RECEIVE_CLIENT_HTTP_READ: received 365 bytes
>>> [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