C library to create simple HTTP servers and Web Applications.

Overview

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.

Introduction

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

Collaborate!

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/.

Download

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'

Dependencies

Required:

  • 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) {
      perror(msg);
      exit(EXIT_FAILURE);
    };

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

    onion_low_initialize_memory_allocation
      (GC_malloc,  GC_malloc_atomic,  GC_calloc,
       GC_realloc, GC_strdup, GC_free,
       memory_failure);
    onion_low_initialize_threads
      (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.

I18N

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

Systemd

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.

FreeBSD/Darwin

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:

  • ONION_LOG

    • 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:

0.4.0

  • 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.
Issues
  • 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(".")));
      onion_listen(o);
      onion_free(o);
      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

    Hi!

    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:

    /path/to/example.php?query=1&test=two&other=three

    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 ...

    Cheers

    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'"

    cmake

    -- 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
    

    make

    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]
        dict->cmp=strcasecmp;
                  ^
    /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

    ./hello
    

    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
  • Random gnutls

    Random gnutls

    Using gnutls to generate pseudo-random data.

    opened by Andrepuel 9
  • 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.

    Thanks,

    Alexander

    opened by solardiz 8
  • 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
  • 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] [192.168.88.125] "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] [192.168.88.125] "GET /" 500 73 (Keep-Alive)

    screen shot 2014-12-20 at 09 48 56

    opened by ihailey 8
  • 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"}' http://127.0.0.1:8080/data

    opened by wjefen 4
  • unsafe fileserver.c example (about Unix signals)

    unsafe fileserver.c example (about Unix signals)

    In commit 2b3b230b79ecae119b7eb847f2 the fileserver.c example has unsafe code about signal (near line 154, calling signal(2) ...)

    Read both signal(7) and signal-safety(7).

    We might take inspiration from Qt5 Unix signal handling, that is use the famous pipe(7) to self trick. Then all the event loops should also poll(2) on that pipe (reading end) and the signal handler would write(2) at least a byte on that pipe (writing end).

    We could also decide to declare some extern volatile sigatomic_t onion_should_stop; variable and have signal handlers setting onion_should_stop and have all the event loops testing that variable repeatedly.

    opened by bstarynk 0
  • Bugfix for onion_websocket_vprintf and onion_websocket_write

    Bugfix for onion_websocket_vprintf and onion_websocket_write

    Hello Mr. Moreno,

    I've spotted a problem with 'onion_websocket_write'. This function will used it's argument 'va_list args' twice, but the pointer in the second call will be wrong. I've found a similar function structure in 'onion_response_vprintf' and copied the solution (va_copy) given there. The remove of '-1' in the first vsnprintf-call is also adapted from there.

    The first commit of this pull request resolves the issue and the problem noted in #275. The second commit just contains changes to trigger the bug with the example application websocket.c

    Other double usages of va_list was not found in 'onion/src'.

    Regards Olaf Schulz

    opened by YggdrasiI 1
  • Wrong return value of 'onion_websocket_write'

    Wrong return value of 'onion_websocket_write'

    Hello Mr Moreno,

    the function 'onion_websocket_write' does not return the correct length information in all cases. If the internal writing is split in multiple parts, only the length of the last token is propagated.

    https://github.com/davidmoreno/onion/blob/2b3b230b79ecae119b7eb847f2f9545a46bef13c/src/onion/websocket.c#L238

    Fix:

    return (ret + (*lpwriter) (ws->req, tout, len & 1023));
    

    Regards Olaf Schulz

    opened by YggdrasiI 0
  • How to build libonion with DWARF debug information and optimizations?

    How to build libonion with DWARF debug information and optimizations?

    For the RefPerSys project (some artificial intelligence open source software), it would be useful to build libonion (on Linux/x86-64) with both optimizations and DWARF enabled. That is to compile libonion's C code with e.g. at least gcc -Wall -O -g (or perhaps gcc -Wall -O2 -g...) and the C++ code with e.g. g++ -Wall -O -g.

    It would also be nice to have written instructions on how to choose the version of GCC; think of some Debian system having both /usr/bin/gcc-9 and /usr/bin/gcc-10.

    Notice that I am unfamiliar with cmake

    Thanks

    opened by bstarynk 1
  • Are websockets blocked?

    Are websockets blocked?

    I try to work with websockets but found that if one websocket is opened, I can't open another (in another tab, another browser or any other PC). How can I fix this bug for opening websockets to given port in any quantity?

    opened by eddyem 6
Releases(v0.8)
  • 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)
🌱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++ 4.7k Dec 3, 2021
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 936 Nov 26, 2021
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 6.5k Dec 6, 2021
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 721 Dec 7, 2021
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 163 Nov 17, 2021
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
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 675 Nov 23, 2021
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 21 Nov 15, 2021
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 6.6k Dec 5, 2021
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 35 Sep 10, 2021
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
Experimental, scalable, high performance HTTP server

Lwan Web Server Lwan is a high-performance & scalable web server. The project web site contains more details. Build status OS Arch Release Debug Stati

Leandro A. F. Pereira 5.5k Dec 2, 2021
A http/websocket server framework on linux.

The framework is a Web-Server on unix based system. Without using any third-party libraries, the framework writes from unix system calls and standard C library functions.

xingyuuchen 12 Dec 7, 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 1.9k Nov 30, 2021
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.5k Dec 2, 2021
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é 231 Nov 26, 2021
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 977 Nov 29, 2021
Corvusoft's Restbed framework brings asynchronous RESTful functionality to C++14 applications.

Restbed Restbed is a comprehensive and consistent programming model for building applications that require seamless and secure communication over HTTP

Corvusoft 1.6k Nov 29, 2021