C library to create simple HTTP servers and Web Applications.


Onion http server library

Travis statusTravis status

Coverity statusCoverity status

Onion is a C library to create simple HTTP servers and Web Applications.

master the development branch. Current stable branch is onion-0-8.


The use case is an existing application, or a new one, that needs some HTTP interconnection with the world. It uses the library to add some handlers for specific URLs and generate and serve the dynamic data as needed.

It also has security goals (SSL support) so that you just concentrate on what you want to serve, and serve it.

Its not a web server per se, as it is not an executable.

If you want to compare to a web server, a web server would use a module or plugin to add some functionality. With libonion you have the functionality and add the webserver as a plugin.

There is a wiki available at https://github.com/davidmoreno/onion/wiki, with useful information on how to get started using Onion and it's internal workings.

API documentation is at http://coralbits.com/static/onion/.

There is a mailing list at https://groups.google.com/a/coralbits.com/forum/?fromgroups=#!forum/onion-dev


You can, and are encouraged, to branch at github, download and tweak onion to use it in your projects.

The library is dual licensed under the Apache2 license and GPLv2+, so you can make almost anything with it, use it in your commercial and free software programs, and modify it to your needs.

Please join the mailing list at https://groups.google.com/a/coralbits.com/group/onion-dev/topics, to ask your questions and comment on your success using onion.

There is also a blog to keep everybody informed about news on onion at http://blog.coralbits.com/.


There are third party packages available:

If you know of any other packaged version, please send me a note.

As always they may be outdated, if you want the latest and greatest, do a manual compile and install.

Thanks to Ruediger Meier for helping for so long with the RPM packages.

Compile and Install

Manual compile and install:

     $ git clone [email protected]:davidmoreno/onion.git
     $ cd onion
     $ mkdir build
     $ cd build
     $ cmake ..
     $ make
     $ sudo make install

To compile with debugging enabled, use

    $ cmake -DCMAKE_BUILD_TYPE=Debug ..

To run with some debug messages, set the ONION_DEBUG and/or ONION_DEBUG0 environment variable containing some source file names, e.g.

    $ export ONION_DEBUG0='request.c url.c'



  • C compiler
  • cmake
  • make
  • One of:

This compilers and minimum versions are known to work:

  • Linux:
    • GCC 4.4
    • clang 3.0

For the C++ bindings a C++11 compiler is needed:

  • Linux:
    • GCC 4.8
    • clang 3.7

Optional; Onion will compile but some functionality will not be available:

  • gnutls and gcrypt (SSL support)
  • pthreads (threading support)
  • libxml2 (WebDAV support)
  • libpam (HTTP Basic Auth support using PAM)
  • C++ compiler
  • Systemd (support for listening on systemd sockets)
  • sqlite3 (sqlite3 session backend)
  • hiredis (Redis session backend)

Optional for examples:

  • cairo
  • libpng2
  • boehm gc
  • libjpeg

Semantic versioning.

Starting with Onion 0.8.0, we use semantic versioning, making the following promises:

  • Version format is [MAJOR].[MINOR].[PATCH].
  • Only make API and ABI changes at major versions. Can add functionalities at minor releases.
  • Only remove API functions at major versions. No changes in semantics never.
  • Minor versions are always ABI back-compatible. This means that if you compiled with a previous minor version and same major version, it will still compile and work.
  • Only add API functions at minor versions.
  • Only fix patches a patch revisions.

Patch revisions are is a non sequential number, so after 0.8.0 is not 0.8.1, but maybe 0.8.23. It will always increase.

Check onion/version.h for more information on version control.

SSL Support

If at compile time the build script finds the gnutls libraries, SSL support will be compiled in. It can be deactivated anyway at ./CMakeLists.txt.

To use it you have to set the certificates, and you can check if its on, checking the flag O_SSL_ACTIVATED.

If support is not compiled in, then the library will not use SSL, but for the user of the library the interface is the same; it will only change that when trying to set the certificates it will fail. Anwyay for clients its just to use the interface and they dont care at all if suport is in or not. No more than being able to use SSL.

This is not mandatory because there may be moments when the program's users do not want to support SSL for whatever reasons, for example speed.

Threads support

Currently there are two threading modes. It can be set so the server is created as threaded (O_THREADED), and it will create a new thread per connection. There is no data protection as on the listen phase there should not be any change to onion structures.

Nevertheless if new handlers are created they must set their own threading support as neccesary.

It can be deactivated at CMakeLists.txt. If no pthreads lib is found on the system, it is not compiled in.

Also when thread support is on, onion server can be set to work on another (non-main) thread. This is independant from O_THREADED operation; it can have one thread with your normal application and another thread that listens and processes web-requests. Its set with the O_DETACH_LISTEN flag. This is very useful when adding an extra web server to your application so it can be added without changes to the flow of your application, but you will need to thread protect your data if you access to it from the web server.

Finally there is a pool mode. Users can set a default number of threads (onion_set_max_threads), and using epoll the data is given to the threads. This is the highest performant method, with up to 30k web-requests served on a Intel(R) Core(TM)2 Duo CPU T6500 @2.10GHz.

Customizing low-level allocation and threads

Sometimes it may be needed to customize memory allocation and/or threads operation. This could be useful when using an alternative malloc, or if you wanted to use Hans Boehm's conservative garbage collector from http://www.hboehm.info/gc/ e.g. if you use GNU guile. Then you need to define your own memory routines and pass them to onion_low_initialize_memory_allocation before any other calls to onion. Likewise, to customize threads operations, call onion_low_initialize_threads. See comments in header file low.h. A program using Onion and Boehm's GC should first define a memory failure routine which should never return:

    /* the memory failure routine should never return! */
    static void memory_failure(const char*msg) {

Then, your program (using both onion and Boehm's GC) should initialize both memory routines and threads, like:

      (GC_malloc,  GC_malloc_atomic,  GC_calloc,
       GC_realloc, GC_strdup, GC_free,
      (GC_pthread_create, GC_pthread_join,
       GC_pthread_cancel, GC_pthread_detach,
       GC_pthread_exit, GC_pthread_sigmask);

You might need to define your GC_calloc using GC_malloc and memset if your version of Boehm's GC don't provide it. After these low-level initialization you can use Onion as usual.

You could also want to call just onion_low_initialize_threads if you wanted to name threads created by the onion library (using pthread_setname_np on Linux) and/or change their priority (using pthread_setschedprio), etc.

ARM Support

It can be cross compiled for ARM directly from cmake. Just do:

	$ mkdir arm
	$ cd arm
	$ cmake .. -DCMAKE_TOOLCHAIN_FILE=../toolchain/arm.txt
	$ make

It needs the current system opack and otemplate to compile some examples, so if you want to use the examples on your instalation, compile and install libonion for the current system first.

Tested on ubuntu 10.10, with gcc-4.5-arm-linux-gnueabi and g++-4.5-arm-linux-gnueabi installed.

Templating support

Starting on 0.3.0 development onion has templating support via otemplate. It is a template system similar to django templates (http://docs.djangoproject.com/en/dev/topics/templates/).

Check more information on how to use them at tools/otemplate/README.rst.


There is I18N support. Check wiki for details or fileserver_otemplate example.


Systemd is integrated. If want to use it, just pass the flag O_SYSTEMD to the onion_new().

Oterm has example socket and service files for oterm support.


Since september 2013 there is support for FreeBSD using libev or libevent. This work is not as tested as the Linux version, but if some compilation error arises, please send the bug report and we will fix it ASAP.

OSX/Darwin support is also available on the darwin branch.

Once this work stabilizes it will be merged back to master.

Environment variables

You can set the following environment variables -e.g. with the export builtin of bash- to modify runtime behaviour of onion:


    • noinfo -- Disables all info output to the console, to achieve faster results
    • nocolor -- Disable color use by the log
    • nodebug -- Do not show debug lines
    • syslog -- Log to syslog. Can be changed programatically too, with the onion_log global function.
  • ONION_DEBUG0 -- Set the filename of a c source file, and DEBUG0 log messages are written. This is normally very verbose.

  • ONION_SENDFILE -- Set to 0 do disable sendfile. Under some file systems it does not work. Until a detection code is in place, it can be disabled with this.

Binary compatibility breaks

We try hard to keep binary compatibility, but sometimes its hard. Here is a list of ABI breaks:


  • Onion object private flags have moved. If on your code you rely on them, must recompile. If dont rely on them, everything should keep working.
  • problems compiling onion example on fedora 20

    problems compiling onion example on fedora 20

    I'm really looking forward to using onion, I just wanted to compile this sample from here (http://coralbits.com/static/onion/)

    #include <onion/onion.h>
    #include <onion/handlers/exportlocal.h>
    #include <onion/handlers/auth_pam.h>
    int main(int argc, char **argv){
      onion *o=onion_new(O_THREADED);
      onion_set_certificate(o, O_SSL_CERTIFICATE_KEY, "cert.pem", "cert.key", O_SSL_NONE);
      onion_set_root_handler(o, onion_handler_auth_pam("Onion Example", "login", onion_handler_export_local_new(".")));
      return 0;

    The instructions say do this:

    gcc -o a a.c -I$ONION_DIR/src/ -L$ONION_DIR/src/onion/ -L$ONION_DIR/src/handlers/ -lonion_handlers -lonion_static -lpam -lgnutls -lgcrypt -lpthread

    But this is what happens on my machine:

    $ gcc -o a a.c -I$ONION_DIR/src/ -L$ONION_DIR/src/onion/ -L$ONION_DIR/src/handlers/  -L/usr/share -lonion_handlers -lonion_static -lpam -L/usr/lib64/libgnutls.so  -L/usr/lib64/libgcrypt.so -lpthread
    /usr/bin/ld: /usr/local/lib/libonion_static.a(sd-daemon.c.o): undefined reference to symbol '[email protected]@GLIBC_2.3.4'
    /usr/bin/ld: note: '[email protected]@GLIBC_2.3.4' is defined in DSO /lib64/librt.so.1 so try adding it to the linker command line
    /lib64/librt.so.1: could not read symbols: Invalid operation

    collect2: error: ld returned 1 exit status

    Any help will really be appreciated!

    opened by gideondsouza 18
  • Add an exception to LGPLv3 for static linking

    Add an exception to LGPLv3 for static linking


    Currently, LGPLv3 forbids static linking. Unless you want to ensure that a user can always rebuild an application with a modified version of onion, it would be convenient to allow static linking as an exception (for people embedding onion statically without modifying it).

    I don't have examples of static linking exception for LGPLv3 but there exists some examples for LGPLv2. There is Ogre (but they switched to a more liberal license later), WxWidgets, 0mq. I cannot say for which reasons the exception was added but I believe this is because of "legit" uses of static linking: easier embedding, platforms where dynamic linking is not available (like iOS), platforms lacking descent package management, easier version management.

    opened by vincentbernat 15
  • Expose a common interface

    Expose a common interface

    Seasons Greetings,

    I'd like to build a sapi module for PHP to use onion as it's HTTP server, http://github.com/krakjoe/ponion initial testing proves this is worth my time and effort, since the first version I can think of kicks the ass out of apache, which is nice :+1:

    Not because I'm lazy, but because I think it will make integration easier, could I ask that you expose some kind of common interface, right now, I'm not sure how to get query strings, paths, translated paths or any of the normal things you need to make some kind of sane HTTP request, I understand the aim of the project is not to be a server but a library, however, these are the existing needs of many many projects that require http functionality.

    Alright, so I'm a bit lazy, I don't mind having to do all of the above by hand, worth a try tho right ??

    Some specific stuff that would be super handy:


    const char* onion_request_get_version(onion_request_) # return 1.0/1.1 const char * onion_request_get_method(onion_request_); # return GET|POST|PATCH|WHATEVER const char* onion_request_get_query_string(onion_request_); # return query=1&blah blah const char_ onion_request_get_file(onion_request*); # return example.php

    // would also be nice: const char* onion_request_get_basepath(onion_request*); # return /path/to

    what might also be nice, is an onion_context_t of onion , onion_request, onion_response*, since this seems like something we'll have to create a lot else, just defining the type would be enough I think, no need for utility functions like ctor/dtor etc ...


    opened by krakjoe 13
  • Jpeg support

    Jpeg support

    Added onion_jpeg_response with similar capabilities like onion_png_response. Depends from libjpeg8. It can be tested with the mandelbrot example application.

    opened by YggdrasiI 12
  • Failed to build in OS X

    Failed to build in OS X "error: implicitly declaring library function 'strcasecmp'"


    -- Using libev as poller
    Gnutls not found. SSL support is not compiled in.
    -- pthreads found. Threading support is compiled in.
    -- libxml2 found. WebDAV support is compiled in.
    -- pam found. PAM support is compiled in in handlers.
    -- libpng found. png support is compiled in at extras.
    -- libcairo found. Adding cairo examples. /usr/local/lib/libcairo.dylib
    -- curl found. Some extra test are compiled.
    librt not found. Systemd support is not compiled in.
    -- Prepared for packaging
    -- libev found at /usr/local/lib/libev.dylib
    -- Compiling WebDAV support
    -- Found include files static.h;exportlocal.h;auth_pam.h;opack.h;path.h;webdav.h;internal_status.h
    -- Found include files png.h
    -- Found include files block.h;codecs.h;dict.h;handler.h;http.h;https.h;listen_point.h;log.h;mime.h;onion.h;poller.h;request.h;response.h;sd-daemon.h;server.h;sessions.h;shortcuts.h;types.h;types_internal.h;url.h;websocket.h
    -- Found include files onion.hpp;dict.hpp;request.hpp;response.hpp;url.hpp;handler.hpp;extrahandlers.hpp
    -- Configuring done
    -- Generating done
    -- Build files have been written to: /Users/jdonat/onion/build


    Scanning dependencies of target onion
    [  1%] Building C object src/onion/CMakeFiles/onion.dir/onion.c.o
    [  2%] Building C object src/onion/CMakeFiles/onion.dir/codecs.c.o
    [  2%] Building C object src/onion/CMakeFiles/onion.dir/dict.c.o
    /Users/jdonat/onion/src/onion/dict.c:84:15: error: implicitly declaring library function 'strcasecmp' with
          type 'int (const char *, const char *)' [-Werror]
    /Users/jdonat/onion/src/onion/dict.c:84:15: note: please include the header <strings.h> or explicitly provide
          a declaration for 'strcasecmp'
    1 error generated.
    make[2]: *** [src/onion/CMakeFiles/onion.dir/dict.c.o] Error 1
    make[1]: *** [src/onion/CMakeFiles/onion.dir/all] Error 2
    make: *** [all] Error 2
    opened by donatj 11
  • cannot run example/hello onUbuntu

    cannot run example/hello onUbuntu

    Hi, I've built example/hello successfully on Ubuntu 10.04. However, when I invoke


    there prints

    [-1210722624] [2013-10-15 13:47:21] [ERROR poller.c:106] Trying to add an invalid file descriptor to the poller. Please check. Segmentation fault. (core dumped)

    Please tell me how to execute the onion apps correctly. Thanks!

    opened by IronBlood 9
  • Added onion version runtime checks.

    Added onion version runtime checks.

    • Adds cmake setting the current version at version.h
    • Functions to get each component and the full version
    • Functions to test current version is ok to use
    • Tests
    opened by davidmoreno 8
  • Race condition fixes using the shutdown() trick, timeout handling speedup, slots preallocation

    Race condition fixes using the shutdown() trick, timeout handling speedup, slots preallocation

    Hi David!

    This is the patch I posted to the onion-dev list a while ago. It isn't exactly clean, but it does the job of making onion work for me seemingly reliably for now (and faster than before, too), and I am not currently aware of any remaining fd or data race conditions in the poller with this patch applied, assuming that the epoll one-shot property works perfectly. (There may still be issues with fd's getting closed on error by other parts of onion, which would trigger races in the poller again. You might want to look into that.)

    I think the fixtimeouts branch is a dead-end (slow, and possibly a less complete fix), at least for the time being, and this patch should be merged instead. This way, we can announce that there were those fatal reliability and security bugs when running with a thread pool and epoll, which are now believed to be fixed. Further cleanups (such as getting rid of the #if 0'ed portions, some of which are actually unsafe, or/and making more invasive changes) can then proceed separately (and will require review and extensive re-testing, as it is all too easy to introduce race conditions again). Maybe you'll need to make a numbered release after merging this patch and before further related changes, so that there is a released version that is (at least potentially) reliable and secure (unlike what we had before, and unlike what further changes might bring), even if still dirty under the hood.



    opened by solardiz 8
  • WebSocket shutdown errors

    WebSocket shutdown errors

    I find that the websockets do not cleanly handle a disconnecting UA client. The logs attached are for the websocket example running on Ubuntu with a Safari 8 UA.

    [B4FDDB40] [2014-12-17 14:53:02] [INFO response.c:182] [] "GET /" 200 437 (Keep-Alive) [B4FDDB40] [2014-12-17 14:53:28] [ERROR websocket.c:434] Error reading websocket header [B4FDDB40] [2014-12-17 14:53:28] [WARNING response.c:206] Trying to set length after headers sent. Undefined onion behaviour. [B4FDDB40] [2014-12-17 14:53:28] [INFO response.c:182] [] "GET /" 500 73 (Keep-Alive)

    screen shot 2014-12-20 at 09 48 56

    opened by ihailey 8
  • 100% cpu usage of otemplate on ARM platform

    100% cpu usage of otemplate on ARM platform


    if I try to compile (no cross compiling) onion on my igep board (ARMv7, beagleboard clone) calls of 'otemplate' do not return. It's seems to me that some loop did not end.

    [ 91%] Built target hello [ 91%] Built target fo_es [ 91%] Built target fo_fr [ 91%] Built target fo_pl [ 91%] Built target fo_zh [ 92%] Generating fileserver_html.c ^Cmake[2]: *** [examples/ofileserver/fileserver_html.c] Interrupt make[1]: *** [examples/ofileserver/CMakeFiles/ofileserver.dir/all] Interrupt make: *** [all] Interrupt

    Did you need any further information?

    Regards, Olaf

    opened by YggdrasiI 7
  • Call of ONION_DEBUG(...) changes input argument

    Call of ONION_DEBUG(...) changes input argument


    on my Android device with Termux (Linux 4.4.156-R3+ aarch64 Android), I've got a strange bug by using otemplate. After some investigation I found out that ONION_DEBUG(const char str) changes its input string argument. I didn't found a solution yet, but if otemplate is affected this bug might also occur at other calls of the macro. I was not able to reproduce the problem on my laptop.

    The position where the bug occurs: tools/otemplate/otemplate.c

    184   const char *tname = basename(tmp2);
    185   ONION_DEBUG("Create init function on top, tname %s", tname);

    After line 184, tname is set correctly to 'some_filename.html'. After line 185, tname is set on 'otemplate.c'.

    Commenting out this line in onion_log_stderr (src/onion/log.c)

    138   filename = basename((char *)filename);

    fixes the issue. So maybe some string pointers share the same memory and POSIX's basename() function is called instead of GNU's basename()? Importing of <libgen.h> triggers the usage of the first variant.

    Regards YggdrasiI

    Steps to reproduce the problem: I compiled everything directly on the device. Maybe it also occurs if the Android NDK will used for cross compiling.

    • Install Termux on Android Smartphone • in Termux: apt install git cmake gcc (note that Termux will install clang instead of gcc) • Setup sshd in Termux or use Adb Shell to avoid typing this stuff directly on the device… • Mkdir '$HOME/includes' and copy Android Header execinfo.h into this folder • Clone onion and Insert the following part into CMakeLists.txt

    if("${CMAKE_SYSTEM_NAME}" EQUAL "Android")  # True in Termux
           # Add folder with execinfo.h
           include_directories(SYSTEM "$HOME/include")
           # Link extra library log on all targets
           macro (add_executable _name)
                   # invoke built-in add_executable
                   if (TARGET ${_name})
                           target_link_libraries(${_name} log)
    endif("${CMAKE_SYSTEM_NAME}" EQUAL "Android")

    Build minimal version of onion with Debug-Build-Type

    mkdir build 
                    cd build && cmake \
                    -DCMAKE_BUILD_TYPE=Debug \
                    -DONION_USE_SSL=false \
                    -DONION_USE_PAM=false \
                    -DONION_USE_PTHREADS=false \
                    -DONION_USE_PNG=false \
                    -DONION_USE_JPEG=false \
                    -DONION_USE_XML2=false \
                    -DONION_USE_SYSTEMD=false \
                    -DONION_USE_SQLITE3=false \
                    -DONION_USE_REDIS=false \
                    -DONION_USE_GC=false \
                    -DONION_USE_TESTS=false \
                    -DONION_EXAMPLES=false \
                    -DONION_USE_BINDINGS_CPP=false \
                    -DONION_POLLER=epoll \
                    .. \
        && make

    And finally, use otemplate to generate a file

    ./build/tools/otemplate/otemplate examples/ofileserver/fileserver.html fileserver_html.c

    This results in an output file with some wrong function names, i.e.

    onion_connection_status otemplate_c_handler_page(onion_dict *context, onion_request *req, onion_response *res){

    Correct would be:

    onion_connection_status fileserver_html_handler_page(onion_dict *context, onion_request *req, onion_response *res){

    opened by YggdrasiI 6
  • Remove null pointer dereferences from #300

    Remove null pointer dereferences from #300

    This commit resolves three null pointer dereferences mentioned by Bogdanisar in #300.

    Comments about changes:

    1. onion.c Add return statement if promotion to https had failed and set member variable only in !=NULL case.

    2. Here, I'm unsure if my change is correct.

    I assume that the NULL-check is using the wrong variable! First of all, a check of the bl variable is missing. This indicates that (bl == NULL) would be the correct check.

    Moreover, the redis session probably should be deleted if the data dict is empty, too. Thus, I changed the line to if (onion_dict_count(data) == 0 || bl == NULL)

    Other variants would be if (bl == NULL) if (data == NULL || bl == NULL )

    1. poller.c: If added a NULL check because poller->head is initialized with NULL in onion_poller_new.
    opened by YggdrasiI 0
  • Null pointer dereferences

    Null pointer dereferences

    Hi! I've run Cppcheck for static code analysis on the master branch of this project. I've found the following 3 code snippets which may contain either a redundant check or a NULL dereference:

    1) At src/onion/onion.c:860:7:

          onion_listen_point *https = onion_https_new();
          https->server = onion;
          if (NULL == https) {
                ("Could not promote from HTTP to HTTPS. Certificate not set.");
          https->port = port;
          https->hostname = hostname;

    If the condition NULL == https can be true, then https->server is a NULL pointer dereference. Statement https->server = onion; was added in commit eaee81e03 , but before that commit the if condition was performed before the assignments. Maybe moving https->server = onion; after the condition is a good fix here?

    2) At src/onion/sessions_redis.c:122:38:

      if (p == NULL) {
        redisReply *reply = redisCommand(p->context, "HDEL SESSIONS %b", session_id,
      } else {
        const char *json = onion_block_data(bl);
        redisReply *reply =
            redisCommand(p->context, "HSET SESSIONS %b %b", session_id,
                         strlen(session_id), json, strlen(json));

    Both code branches execute redisCommand(p->context, ...), but p is NULL for the first branch, so p->context will be a NULL pointer dereference.

    3) At src/onion/poller.c:453:10:

      if (el && el->fd == fd) {
      while (el->next) {

    If el can be NULL, then the statement while (el->next) will be a NULL pointer dereference. If not, the condition el && from if (el && el->fd == fd) is redundant.

    opened by Bogdanisar 0
  • Cannot authenticate on Centos7 with PAM enabled

    Cannot authenticate on Centos7 with PAM enabled


    For what documentation i have saw, i should be able to connect to oterm, in the chosen tcp port with my local account credentials. However, i cannot get access.

    I have been getting this error, on centos7, no selinux enabled inside an lxc container.

    [WARNING auth_pam.c:180] NOT authenticated user 'nuno', code 7

    What am i missing? Is there a chapter in the documentation that can explain what code 7 stands for?

    Thanks Nuno

    opened by NunoHiggs 0
  • Wiki pages edit access

    Wiki pages edit access

    Wiki pages' editing access is public. Any spammer may destroy the pages resulting in a chaos in the library wiki So it is requested to restrict the edit access

    opened by rituparna-ui 0
  • can not get post data by example

    can not get post data by example "post"

    i send date by curl,but can't get any data i trace it, the dict's key was data,not content-type,is it bug?

    debug info: onion_dict_find_node (d=0x615df0, current=0x62a220, key=0x400e58 "application", parent=0x0) at */onion-master/src/onion/dict.c:231 231 if (!current) { (gdb) n 234 int cmp = d->cmp(key, current->data.key); (gdb) p key $79 = 0x400e58 "application" #### I modify the example (text->application) (gdb) p current->data.key #### it is debug data saved to dict $80 = 0x615da0 "{"input_1": "111sunshine"}"

    the cmd i used: curl --trace test.txt --data '{"input_1": "111sunshine"}'

    opened by wjefen 4
  • v0.8(Apr 29, 2016)

    Features and improvement in no special order:

    1. Stability improvements on the poller (Thanks to Solar designer for help tracking it, idea by Rich Felker, fixed by David Moreno).
    2. Performance improvements on onion_log (Zachary Grafton)
    3. Many bugs found by clang thread sanitizer and fixed. (Zachary Grafton)
    4. Improvements to JSON encode/decode (Thanks to Solar designer for help tracking it, fixed by David Moreno)
    5. Undefined behaviour fixes (Zachary Grafton)
    6. CPP bindings (David Moreno, Zachary Grafton)
    7. Redis sessions (Zachary Grafton)
    8. Rework on request parser to allow OCS_YIELD (David Moreno).
    9. Overall API improvements (David Moreno)
    10. Use of custom low level functions: onion_malloc, onion_free... (Basile Starynkevitch)
    11. Bohem GC support (Basile Starynkevitch)
    12. Man pages for the tools. (David Moreno)
    13. Semantic Versioning.
    14. Many small fixes and improvements.
    Source code(tar.gz)
    Source code(zip)
Tntnet is a web application server for web applications written in C++.

Tntnet is a web application server for web applications written in C++.

Tommi Mäkitalo 73 Sep 26, 2022
🌱Light and powerful C++ web framework for highly scalable and resource-efficient web application. It's zero-dependency and easy-portable.

Oat++ News Hey, meet the new oatpp version 1.2.5! See the changelog for details. Check out the new oatpp ORM - read more here. Oat++ is a modern Web F

Oat++ 5.9k Dec 5, 2022
C++ application development framework, to help developers create and deploy applications quickly and simply

ULib - C++ library Travis CI: Coverity Scan: ULib is a highly optimized class framework for writing C++ applications. I wrote this framework as my too

stefano casazza 949 Nov 22, 2022
Drogon: A C++14/17 based HTTP web application framework running on Linux/macOS/Unix/Windows

English | 简体中文 | 繁體中文 Overview Drogon is a C++14/17-based HTTP application framework. Drogon can be used to easily build various types of web applicat

An Tao 8.4k Dec 1, 2022
A high performance, middleware oriented C++14 http web framework please use matt-42/lithium instead

A high performance, middleware oriented C++14 http web framework please use matt-42/lithium instead

Matthieu Garrigues 1.7k Nov 20, 2022
A C++ Web Framework built on top of Qt, using the simple approach of Catalyst (Perl) framework.

Cutelyst - The Qt Web Framework A Web Framework built on top of Qt, using the simple and elegant approach of Catalyst (Perl) framework. Qt's meta obje

Cutelyst 804 Nov 25, 2022
A C++11 RESTful web server library

Served Overview Served is a C++ library for building high performance RESTful web servers. Served builds upon Boost.ASIO to provide a simple API for d

Meltwater 695 Oct 12, 2022
Embeddable Event-based Asynchronous Message/HTTP Server library for C/C++

libasyncd Embeddable Event-based Asynchronous Message/HTTP Server library for C/C++. What is libasyncd? Libasyncd is an embeddable event-driven asynch

Seungyoung 165 May 25, 2022
bittyhttp - A threaded HTTP library for building REST services in C.

bittyhttp - A threaded HTTP library for building REST services in C.

Colin Luoma 12 Nov 29, 2021
Pistache is a modern and elegant HTTP and REST framework for C++

Pistache is a modern and elegant HTTP and REST framework for C++. It is entirely written in pure-C++17* and provides a clear and pleasant API.

null 2.8k Dec 4, 2022
A Zig binding to the webview library. Make Zig applications with a nice HTML5 frontend a reality!

A Zig binding to the webview library. Make Zig applications with a nice HTML5 frontend a reality!

ZigLibs 50 Nov 23, 2022
Crow is very fast and easy to use C++ micro web framework (inspired by Python Flask)

Crow is C++ microframework for web. (inspired by Python Flask) #include "crow.h" int main() { crow::SimpleApp app; CROW_ROUTE(app, "/")([]()

Jaeseung Ha 7k Nov 28, 2022
cserv is an event-driven and non-blocking web server

cserv is an event-driven and non-blocking web server. It ideally has one worker process per cpu or processor core, and each one is capable of handling thousands of incoming network connections per worker. There is no need to create new threads or processes for each connection.

null 43 Nov 6, 2022
This is a proof-of-concept of a modern C web-framework that compiles to WASM and is used for building user interfaces.

DanCing Web ?? ?? (DCW) Getting Started Dancing Web is now distributed with the Tarantella Package Manager — a tool I've made to simplify setup of pro

Danilo Chiarlone 3 Sep 11, 2021
Embedded C/C++ web server

CivetWeb The official home of CivetWeb is https://github.com/civetweb/civetweb Continuous integration for Linux and macOS (Travis CI): Continuous inte

null 2.2k Nov 24, 2022
Your high performance web application C framework

facil.io is a C micro-framework for web applications. facil.io includes: A fast HTTP/1.1 and Websocket static file + application server. Support for c

Bo 1.7k Dec 2, 2022
QDjango, a Qt-based C++ web framework

QDjango - a Qt-based C++ web framework Copyright (c) 2010-2015 Jeremy Lainé About QDjango is a web framework written in C++ and built on top of the Qt

Jeremy Lainé 247 Nov 14, 2022
TreeFrog Framework : High-speed C++ MVC Framework for Web Application

Small but Powerful and Efficient TreeFrog Framework is a high-speed and full-stack web application framework based on C++ and Qt, which supports HTTP

TreeFrog Framework 1.1k Dec 4, 2022