Copyright ©

Mongoose OS Forum


Enabling Keep-Alive

Hi. I am using the mongoose web server to serve a webpage from an ESP32 microcontroller.
However, I have problems with enabling keep-alive on the webserver. This is especially a problem when enabling TLS, as it causes a handshake to be performed for every css and javascript file which needs to be performed. This causes very long loadtimes (~10 seconds) and high memory usage on the ESP32, as it is trying to perform several handshakes at the same time.

I have compiled using MG_DISABLE_HTTP_KEEP_ALIVE=0. Is there anything further which needs to be done to enable this future? And is it possible to have more fine-grained control over the keep-alive settings, e.g., how many connections are kept open, and how long they will be kept?

Best Regards


  • SergeySergey Dublin, Ireland
    edited March 2017

    Keep-alive is the default.
    Please describe in a bit more detail - what you're doing exactly, what do you see, and what do you expect to see.

    Your current description does not make it easy to reproduce.

  • Hi
    Thanks for your reply.
    When serving webpages using mongoose, it seems that keep-alive is not being enabled properly.

    If analyzing the connection using the network monitor tool in firefox, i see the following HTTP headers:

    Request headers:

    User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    DNT: 1
    Authorization: Digest username="test", realm="all", nonce="17", uri="/index.shtml", response="3afc7bff86b41c336e1cc44c55b27dd9", qop=auth, nc=0000013c, cnonce="80d70dc272297c40"
    Connection: keep-alive
    Upgrade-Insecure-Requests: 1
    Pragma: no-cache
    Cache-Control: no-cache

    Response headers:

    Connection: close
    Content-Type: text/html
    Server: Mongoose/6.7

    I expected a response from mongoose with 'Connection: keep-alive'

    Because mongoose returns Connection: close, firefox establishes new connections when requesting the css and javascript files refered in index.shtml. However, it seems that keep-alive works correctly when serving these files, as the response header contains 'Connection: keep-alive'

    While investigating the issue, I have found that the issue seems to have something to do with server-side includes, as compiling with MG_ENABLE_HTTP_SSI=0 results in the expected response headers (however, doing this obviously breaks the html files as i depend on SSI.).

    Indeed, looking at the mongoose source code, it seems that keep-alive are being disabled for files where server-side includes are used.

    Is this correct? Is keep-alive not supported when serving files using SSI?

    Best Regards

  • SergeySergey Dublin, Ireland

    Your questions is asked so often, it probably deserves some sort of FAQ..

    You can pipeline requests / responses when you know message boundaries. Message boundaries could be known using two methods: a) chunked encoding, b) setting content-length header.

    Your request does not use either. So, to solve your issue, either set content-length, or use chunked encoding.

  • I see.
    Is there any "standard" way to do this in mongoose? I would like to avoid rewriting large parts of the SSI handling if possible. Is it maybe possible to make mongoose wait until the entire response is generated, and then set the content length before sending the body? The html files i am serving are quite small, (about 1-4 KB), so it should not be too much of a problem to have the whole file in memory.


  • SergeySergey Dublin, Ireland
    edited March 2017

    I suggest using chunked encoding.

    Take a look at the restful server example, a function that grabs parameters from the POST body, calculates their sum, and writes back a JSON response:

    There could be a sequence of mg_printf_http_chunk() calls with non-0 length. At the end, a zero-length chunk should go, which marks the end of the body.

Sign In or Register to comment.