[Libwebsockets] force closing http 1.1 or http2 connection from user side
andy at warmcat.com
andy at warmcat.com
Wed Apr 21 05:07:36 CEST 2021
On April 20, 2021 11:21:04 PM UTC, sas spss <sas2016spss at gmail.com> wrote:
>Thanks for info. Just to confirm that the simple way ( #define
>lws_wsi_close(w, to_kill) lws_set_timeout(w, 1, to_kill ) is to kill
>connection before returning. So the caller of
You can choose, that is the meaning of the _SYNC (before returning) and _ASYNC (next time around the event loop). _SYNC can't be used where a parent caller in the call stack holds a reference to the same wsi, ie, _ASYNC is usually what you want.
lws_wsi_close() needs to
>sure the wsi of the closed connection will no longer be used after the
>lws_wsi_close call. Correct ? This way also works for https with
Depending on the protocol the close may be staged, ie, send out a close frame first then close the stream. Bit it will typically close it very quickly.
On h2 it's the same, but it just closes the stream, not the underlying tcp / tls until it has been idle (no streams active) for some time.
>Another question: is there a way in libwebsocket to close the file
>descriptor and wsi associated with the TCP connection without sending
>anything (no FIN or RST) back to the other end ? This can help slow
>bad clients that keep trying to spam the service.
You can look at PEER_LIMITS optipn, but there is no way to do exactly that from posix userland afaik. It sounds like you need some kind of iptables type solution that DROPs all traffic from IPs you decided you don't like, in front of lws. Then just let any existing conns timeout cleanly.
The real bad guys have huge botnets, there's a limited amount you can do at server layer.
>On Tue, Apr 20, 2021 at 12:41 PM <andy at warmcat.com> wrote:
>> On April 20, 2021 7:21:17 PM UTC, sas spss <sas2016spss at gmail.com>
>> >When the server found an invalid authentication header / cookie in a
>> >http1.1 keep alive or http2 connectiion, the server wants to close
>> >connection right away to prevent file descriptors being used up by
>> >kind of spam (fake API calls).
>> For h1, the transaction is directly on the tcp conn, so closing one
>> closing the other.
>> >According to the libwebsocket doc, I called lws_callback_on_writable
>> >) to trigger a writable callback. And then inside of the actual
>> >under "case LWS_CALLBACK_HTTP_WRITEABLE", I return -1 for closing
>> You can do that, but there is a simpler way
>> Usually you want the _ASYNC version to close it next time around the
>> >In my test with "curl --http1.1 url1 url2 ", the url1 request has
>> >authentication header which triggers above return -1 in writable
>> >But curl shows url2 still being served with debug message "re-using
>> >existing connection ...".
>> Not sure I understand that... returning -1 on writeable for h1 will
>> it. H1 keepalive is really fragile, everything has to have been
>> just right to be able to chain on anotjer transaction.
>> >So it seems the TCP connection is not closed and still being used as
>> >keep-alive connection. Is this the expected behavior ?
>> Check the verbose logs. And use the latest version.
>> If yes, what's
>> >best way to close the connection as quickly as possible so the
>> >recycle the file descriptor from many of the un-authenticated
>> For h1 what you're doing should work afaik.
>> >In another situation, like regular user login error, which server
>> >to send a response with http code 401 back to browser before close
>> >connection. I can't close the connection right after composing the
>> >response since there are still data (http code 401, etc) in send
>> >buffer. I
>> >tried to return -1 in writable callback under "case
>> >LWS_CALLBACK_HTTP_DROP_PROTOCOL", but that doesn't seem to close the
>> >connect either and still allow the next request in keep-alive
>> >being served.
>> >In 2nd situation, what's the best way to schedule closing the TCP
>> >connection after the current HTTP response being sent ?
>> The link earlier shows how to do it without having to close the
>> part yourself.
>> >Thanks a lot,
More information about the Libwebsockets