[Libwebsockets] lws_client_connect_via_info() - protocol 0 handler

Andy Green andy at warmcat.com
Wed Feb 15 21:18:13 CET 2017



On February 16, 2017 12:26:04 AM GMT+08:00, Joel Winarske <joel.winarske at gmail.com> wrote:
>Hi Andy,
>
>First off, thank you.  This makes the client callbacks work with lwsws.
>Log below.
>
>The only thing odd, perhaps unrelated to this change is the two
>callbacks
>with the same data.  Is this expected behavior?
>1.  LWS_CALLBACK_RECEIVE_CLIENT_HTTP_READ: 316
>2.  LWS_CALLBACK_RECEIVE_CLIENT_HTTP: 316

Look at how the current test client deals with this, this is needed to deal with

 - the ability to be notified of incoming rx, but user code to choose to defer taking it until something else is writable

 - to be able to eat multiple chunks in chunked encoding from one rx, concealing the inline chunking headers

If you are already following the test client method, this is something lwsws-specific I guess.  The test client doesn't do that on chunked or unchunked http urls.

>Also curious, but perhaps an OpenSSL question; how to dump out what
>cipher
>is being attempted.

I don't know, it's indeed some OpenSSL specific thing.  There's a callback from the OpenSSL verify routine you probably have everything you need there.

Note you can restrict the ciphers OpenSSL will allow in lws, per vhost.  The list in the test server is that necessary to restrict the valid list to be for PFS only / to get the A+ SSL certification at SSL labs.

-Andy

>Thanks,
>Joel
>
>[2017/02/15 08:08:49:1879] NOTICE: http client: connecting
>[2017/02/15 08:08:49:1879] INFO: lws_ensure_user_space: 02B11728
>protocol
>00B1F578
>[2017/02/15 08:08:49:1879] INFO: lws_header_table_attach: wsi 02B11728:
>ah
>00000000 (tsi 0, count = 1) in
>[2017/02/15 08:08:49:1879] INFO: lws_header_table_attach: wsi 02B11728:
>ah
>00B56AA0: count 2 (on exit)
>[2017/02/15 08:08:49:1879] NOTICE: lws_client_connect_2: address
>uas-api.inrix.com
>[2017/02/15 08:08:49:2164] INFO: http: 29: v=02A6E2A8, ctx=00B44408
>[2017/02/15 08:08:49:2169] INFO: lws_client_connect_via_info: created
>child
>02B11728 of parent 02869888
>[2017/02/15 08:08:49:2169] NOTICE: lws_client_connect_via_info
>sucessful
>wsi=02B11728
>[2017/02/15 08:08:49:2169] INFO: lws_read: read_ok, used 402
>[2017/02/15 08:08:49:2344] NOTICE: lws_client_connect_2: address
>uas-api.inrix.com
>[2017/02/15 08:08:49:2584] NOTICE: lws_ssl_client_connect2: SSL_connect
>says -1
>[2017/02/15 08:08:49:2584] INFO: SSL_connect WANT_READ... retrying
>[2017/02/15 08:08:49:2589] NOTICE: lws_ssl_client_connect2: SSL_connect
>says -1
>[2017/02/15 08:08:49:2589] INFO: SSL_connect WANT_READ... retrying
>[2017/02/15 08:08:49:2599] NOTICE: accepting self-signed certificate
>[2017/02/15 08:08:49:2619] NOTICE: lws_ssl_client_connect2: SSL_connect
>says -1
>[2017/02/15 08:08:49:2619] INFO: SSL_connect WANT_READ... retrying
>[2017/02/15 08:08:49:2807] NOTICE: lws_ssl_client_connect2: SSL_connect
>says 1
>[2017/02/15 08:08:49:3006] INFO: lws_ensure_user_space: 02B11728
>protocol
>00B1F578
>[2017/02/15 08:08:49:3006] INFO: lws_ensure_user_space: 02B11728
>protocol
>pss 9252, user_space=02B27230
>[2017/02/15 08:08:49:3006] NOTICE:
>lws_client_interpret_server_handshake:
>incoming content length 316
>[2017/02/15 08:08:49:3006] INFO: http:
>LWS_CALLBACK_CLIENT_FILTER_PRE_ESTABLISH: v=02A6E2A8, ctx=00B44408
>[2017/02/15 08:08:49:3006] INFO: http:
>LWS_CALLBACK_ESTABLISHED_CLIENT_HTTP: 200
>[2017/02/15 08:08:49:3006] INFO: lws_header_table_detach: wsi 02B11728:
>ah
>00B56AA0 (tsi=0, count = 2)
>[2017/02/15 08:08:49:3006] INFO: lws_header_table_detach: wsi 02B11728:
>ah
>00B56AA0 (tsi=0, count = 1)
>[2017/02/15 08:08:49:3006] NOTICE:
>lws_client_interpret_server_handshake:
>client connection up
>[2017/02/15 08:08:49:3011] INFO: ssl buffered read
>[2017/02/15 08:08:49:3011] INFO: http:
>LWS_CALLBACK_RECEIVE_CLIENT_HTTP_READ: 316
>[2017/02/15 08:08:49:3011] INFO: lws_http_transaction_completed_client:
>02B11728: keep-alive await new transaction
>[2017/02/15 08:08:49:3011] INFO: http:
>LWS_CALLBACK_RECEIVE_CLIENT_HTTP: 316
>[2017/02/15 08:08:49:3011] INFO: lws_read: read_ok, used 0
>[2017/02/15 08:08:52:3777] INFO: lws_close_free_wsi: real
>just_kill_connection: 02868CA8 (sockfd 508)
>[2017/02/15 08:08:52:3777] INFO: remove_wsi_socket_from_fds: removing
>same
>prot wsi 02868CA8
>[2017/02/15 08:08:52:3777] INFO: lws_close_free_wsi: real
>just_kill_connection: 0286C0B8 (sockfd 496)
>[2017/02/15 08:08:52:3777] INFO: remove_wsi_socket_from_fds: removing
>same
>prot wsi 0286C0B8
>[2017/02/15 08:08:52:3782] INFO: ah det due to close
>
>
>
>
>On Tue, Feb 14, 2017 at 5:18 PM, Andy Green <andy at warmcat.com> wrote:
>
>>
>>
>> On 02/15/2017 01:50 AM, Joel Winarske wrote:
>>
>>> Hi Andy,
>>>
>>> How do I override the http client protocol handler in the case of
>lwsws?
>>>
>>
>> It looks like it should ideally be done by setting the .vhost and the
>> .protocol name in the connect info.  But not supported until now.
>>
>>
>>> When I set info.protocol to my protocol name, it has no effect.
>>>
>>> In lws_client_connect_via_info() I see the following; which for
>lwsws
>>> assigns it to "http-only":
>>>
>>> wsi->protocol = &wsi->vhost->protocols[0];
>>>
>>
>> That doesn't mean much though since it knows it will generate
>callbacks in
>> the process of connecting, and when no better protocol is capable of
>being
>> selected (because for ws it must be negotiated with the server), lws
>uses
>> protocols[0] for want of anything better in many places.
>>
>> Client connections were until recently all ws/wss, for that this will
>work
>> fine since the protocol is negotiated and selected later.
>>
>> For HTTP[S] client until now no code to allow forcing the protocol
>> selection... that works fine with all on protocols[0] in "by hand"
>code
>> like the original test server.  But being able to target a specific
>plugin
>> / protocol handler by name makes a lot more sense inside lwsws.
>>
>> Please try this
>>
>> https://github.com/warmcat/libwebsockets/commit/d23cb338654c
>> 423e74c0b0160ba275e9a57c0070
>>
>> pushed on master just now.
>>
>> Set the info .vhost, the protocol name you want on that vhost in the
>info
>> .protocol and there should be an info.method set already indicating
>http
>> GET or whatever.  Then it will attempt to select the protocol from
>the
>> vhost early in the connection action.
>>
>> -Andy
>>
>>
>>>
>>> Thanks,
>>> Joel
>>>
>>>
>>> _______________________________________________
>>> Libwebsockets mailing list
>>> Libwebsockets at ml.libwebsockets.org
>>> https://libwebsockets.org/mailman/listinfo/libwebsockets
>>>
>>
>>



More information about the Libwebsockets mailing list