[Libwebsockets] force closing http 1.1 or http2 connection from user side

andy at warmcat.com andy at warmcat.com
Tue Apr 20 21:41:47 CEST 2021

On April 20, 2021 7:21:17 PM UTC, sas spss <sas2016spss at gmail.com> wrote:
>When the server found an invalid authentication header / cookie in a
>http1.1 keep alive or http2 connectiion, the server wants to close the
>connection right away to prevent file descriptors being used up by this
>kind of spam (fake API calls).

For h1, the transaction is directly on the tcp conn, so closing one is 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 event loop.

>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 close it. H1 keepalive is really fragile, everything has to have been consumed 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 server
>recycle the file descriptor from many of the un-authenticated requests

For h1 what you're doing should work afaik.

>In another situation, like regular user login error, which server does
>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 second part yourself.


>Thanks a lot,

More information about the Libwebsockets mailing list