A high-performance REST Toolkit written in C++




Build Status

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


We are still looking for a volunteer to document fully the API. In the mean time, partial documentation is available at http://pistache.io. If you are interested in helping with this, please open an issue ticket.


Pistache has the following third party dependencies


Pistache is released under the Apache License 2.0. Contributors are welcome!

Pistache was originally created by Mathieu Stefani, but he is no longer actively maintaining Pistache. A team of volunteers has taken over. To reach the original maintainer, drop a private message to @octal in cpplang Slack channel.

For those that prefer IRC over Slack, the rag-tag crew of maintainers idle in #pistache on Freenode. Please come and join us!

The Launchpad Team administers the daily and stable Ubuntu pre-compiled packages.

Release Versioning

Please update version.txt accordingly with each unstable or stable release.

Interface Versioning

The version of the library's public interface (ABI) is not the same as the release version. The interface version is primarily associated with the external interface of the library. Different platforms handle this differently, such as AIX, GNU/Linux, and Solaris.

GNU Libtool abstracts each platform's idiosyncrasies away because it is more portable than using ar(1) or ranlib(1) directly. However, it is a pain to integrate with CMake so we made do without it by setting the SONAME directly.

When Pistache is installed it will normally ship:

  • libpistache-<release>.so.X.Y: This is the actual shared-library binary file. The X and Y values are the major and minor interface versions respectively.

  • libpistache-<release>.so.X: This is the soname soft link that points to the binary file. It is what other programs and other libraries reference internally. You should never need to directly reference this file in your build environment.

  • libpistache-<release>.so: This is the linker name entry. This is also a soft link that refers to the soname with the highest major interface version. This linker name is what is referred to on the linker command line. This file is created by the installation process.

  • libpistache-<release>.a: This is the static archive form of the library. Since when using a static library all of its symbols are normally resolved before runtime, an interface version in the filename is unnecessary.

If your contribution has modified the interface, you may need to update the major or minor interface versions. Otherwise user applications and build environments will eventually break. This is because they will attempt to link against an incorrect version of the library -- or worse, link correctly but with undefined runtime behaviour.

The major version should be incremented every time a non-backward compatible change occured in the ABI. The minor version should be incremented every time a backward compatible change occurs. This can be done by modifying version.txt accordingly.

Precompiled Packages

If you have no need to modify the Pistache source, you are strongly recommended to use precompiled packages for your distribution. This will save you time.

Debian and Ubuntu

We have submitted a Request for Packaging downstream to Debian. Once we have an official Debian package maintainer intimately familiar with the Debian Policy Manual, we can expect to eventually see it become available in Debian and all derivatives (e.g. Ubuntu and many others).

But until then currently Pistache has partially compliant upstream Debianization. Our long term goal is to have our source package properly Debianized downstream by a Debian Policy Manual SME. In the mean time consider using our PPAs to avoid having to build from source.

Supported Architectures

Currently Pistache is built and tested on a number of architectures. Some of these are suitable for desktop or server use and others for embedded environments. As of this writing we do not currently have any MIPS related packages that have been either built or tested. The ppc64el builds are occasionally tested on POWER9 hardware, courtesy of IBM.

  • amd64
  • arm64
  • armhf
  • i386
  • ppc64el
  • s390x

Ubuntu PPA (Unstable)

The project builds daily unstable snapshots in a separate unstable PPA. To use it, run the following:

$ sudo add-apt-repository ppa:pistache+team/unstable
$ sudo apt update
$ sudo apt install libpistache-dev

Ubuntu PPA (Stable)

Currently there are no stable release of Pistache published into the stable PPA. However, when that time comes, run the following to install a stable package:

$ sudo add-apt-repository ppa:pistache+team/stable
$ sudo apt update
$ sudo apt install libpistache-dev

Other Distributions

Package maintainers, please insert instructions for users to install pre-compiled packages from your respective repositories here.

Use via pkg-config

If you would like to automatically have your project's build environment use the appropriate compiler and linker build flags, pkg-config can greatly simplify things. It is the portable international de facto standard for determining build flags. The development packages include a pkg-config manifest.

GNU Autotools

To use with the GNU Autotools, as an example, include the following snippet in your project's configure.ac:

    # Pistache...
        [libpistache], [libpistache >= 0.0.2], [],
        [AC_MSG_ERROR([libpistache >= 0.0.2 missing...])])


To use with a CMake build environment, use the FindPkgConfig module. Here is an example:

    cmake_minimum_required(3.4 FATAL_ERROR)

    # Find the library.
    find_package(Pistache 0.0.2 REQUIRED)

    add_executable(${PROJECT_NAME} main.cpp)
    target_link_libraries(${PROJECT_NAME} pistache_shared)


To use within a vanilla makefile, you can call pkg-config directly to supply compiler and linker flags using shell substitution.

    CFLAGS=-g3 -Wall -Wextra -Werror ...
    LDFLAGS=-lfoo ...
    CFLAGS+= $(pkg-config --cflags libpistache)
    LDFLAGS+= $(pkg-config --libs libpistache)

Building from source

To download the latest available release, clone the repository over github.

    $ git clone https://github.com/oktal/pistache.git

Then, init the submodules:

    $ git submodule update --init

Now, compile the sources:

    $ cd pistache
    $ mkdir -p {build,prefix}
    $ cd build
    $ cmake -G "Unix Makefiles" \
        -DCMAKE_BUILD_TYPE=Release \
        -DPISTACHE_BUILD_DOCS=false \
        -DPISTACHE_USE_SSL=true \
        -DCMAKE_INSTALL_PREFIX=$PWD/../prefix \
    $ make -j
    $ make install

If you chose to build the examples, then perform the following to build the examples.

    $ cd examples
    $ make -j

Optionally, you can also build and run the tests (tests require the examples):

    $ cmake -G "Unix Makefiles" -DPISTACHE_BUILD_EXAMPLES=true -DPISTACHE_BUILD_TESTS=true ..
    $ make test test_memcheck

Be patient, async_test can take some time before completing. And that's it, now you can start playing with your newly installed Pistache framework.

Some other CMAKE defines:

Option Default Description
PISTACHE_BUILD_EXAMPLES False Build all of the example apps
PISTACHE_BUILD_TESTS False Build all of the unit tests
PISTACHE_ENABLE_NETWORK_TESTS True Run unit tests requiring remote network access
PISTACHE_USE_SSL False Build server with SSL support

Continuous Integration Testing

It is important that all patches pass unit testing. Unfortunately developers make all kinds of changes to their local development environment that can have unintended consequences. This can means sometimes tests on the developer's computer pass when they should not, and other times failing when they should not have.

To properly validate that things are working, continuous integration (CI) is required. This means compiling, performing local in-tree unit tests, installing through the system package manager, and finally testing the actually installed build artifacts to ensure they do what the user expects them to do.

The key thing to remember is that in order to do this properly, this all needs to be done within a realistic end user system that hasn't been unintentionally modified by a developer. This might mean a chroot container with the help of QEMU and KVM to verify that everything is working as expected. The hermetically sealed test environment validates that the developer's expected steps for compilation, linking, unit testing, and post installation testing are actually replicable.

There are different ways of performing CI on different distros. The most common one is via the international DEP-8 standard as used by hundreds of different operating systems.


On Debian based distributions, autopkgtest implements the DEP-8 standard. To create and use a build image environment for Ubuntu, follow these steps. First install the autopkgtest(1) tools:

$ sudo apt install autopkgtest

Next create the test image, substituting groovy or amd64 for other releases or architectures:

$ autopkgtest-buildvm-ubuntu-cloud -r groovy -a amd64

Generate a Pistache source package in the parent directory of pistache_source:

$ cd pistache_source
$ sudo apt build-dep pistache
$ ./debian/rules get-orig-source
$ debuild -S -sa -uc

Test the source package on the host architecture in QEMU with KVM support and 8GB of RAM and four CPUs:

$ autopkgtest --shell-fail --apt-upgrade ../pistache_(...).dsc -- \
      qemu --ram-size=8192 --cpus=4 --show-boot path_to_build_image.img \


Hello World (server)

#include <pistache/endpoint.h>

using namespace Pistache;

struct HelloHandler : public Http::Handler {
  void onRequest(const Http::Request&, Http::ResponseWriter writer) override{
    writer.send(Http::Code::Ok, "Hello, World!");

int main() {
  • Add Meson support

    Add Meson support

    This PR addresses a few things: Meson support, a fix to parse_RFC_850(), re-add support for code coverage in CMake and update Travis config. All the details about this four things are in their respective commit description :)

    If you don't know what Meson is, I highly recommend you to check it out. Meson build files are far more readable and maintainable than CMake ones, and the build system is also faster, which is never a bad thing.

    opened by Tachi107 47
  • Can someone describe the process of installing Pistache on Centos 6.5 etc

    Can someone describe the process of installing Pistache on Centos 6.5 etc

    I have actually finished my program and it does exactly what I want, but I have been doing it in codeblocks on a Ubuntu system. So now I want to run my program on a Centos headless server. I have made a Makefile and my Makefile works on Ubuntu without errors, but then pistache is installed.

    So I was wondering if someone could talk me through the process of installing Pistache on Centos. Is there a yum command to install pistache or do I just clone pistache from git and use the Makefile to build it and then copy the pistache folder to my project?

    Bear in mind I am new to linux and I usually do everything in windows, so if my question sounds stupid then that is why.

    opened by Asimov500 45
  • fix #1030

    fix #1030

    1. Keep-alive connection server endpoint, send 408 message after idle timeout, it's not expected.
    2. I add an keep-alive timeout option. Before starting the HTTP service, you can set the keepalive time for the long connection. If the keepalive time exceeds this value, you can disable the long connection.
    3. I use tcpdump capture packet, confirming that 408 is not sent and the connection is directly closed.
    bug fix in progress 
    opened by zydxhs 40
  • ci: build on multiple Linux distributions

    ci: build on multiple Linux distributions

    This new CI job builds and tests Pistache on different Linux distros, with different compilers, and under different sanitizers, and also re-adds Codecov coverage integration back.

    Currently, Pistache is tested on Debian Stable, Debian Testing and Red Hat Enterprise Linux 8, and the code is built with GCC and Clang. Sanitizers are only used on Debian, because as far as I'm aware RHEL doesn't ship the various sanitizers in its base images.

    ThreadSanitizer is also disabled for now, as it reports a lot of data races in some tests. Some of the bugs are in the unit tests themselves, but I haven't yet looked into solving them. @dennisjenkins75 I seem to remember that you opened a meta-issue about dace conditions in Pistache but I haven't found it.

    ~I'll add RHEL 9 as soon as Red Hat publishes the image on Docker Hub~ added using Red Hat's own registry

    It would be nice to add something like Gentoo too; @dennisjenkins75 you use/used Gentoo, right? Would you be able to help?

    ~I've also fixed a bug in the streaming_test test that caused lock ups on old distros (@kiplingw this means that PPA builds for Ubuntu 20.10 and older should be fixed as well)~ pushed as 8ce07256dc220cbf96b3fd6f5991a3c68fd54aba

    Lastly, I ~removed~ reduced the scope of the autopkgtest job; you can find my rationale in the commit message.

    opened by Tachi107 35
  • Possible solution for BUG#1007

    Possible solution for BUG#1007

    I'm also currently facing the issue described in #1007. I added the MSG_NOSIGNAL Flag as proposed by @amang8662. But there was still the problem, how to get the info if the socket is still alive. So I checked on the documentation (https://linux.die.net/man/3/getsockopt). With the function getsockopt() you are able to receive the last error of the socket. In case the pipe breaks, the error is returned through this function. So we can check if the stream is still alive by testing the return value.

    I added the function isOpen() which returns true if there isn't an error on the socket and false otherwise.

    This is my first PR in any open-source project. So I hope for leniency.

    bug fix in progress 
    opened by IHni3 33
  • Dynamic arraybuf

    Dynamic arraybuf

    • Changed ingestion buffer to std::vector instead of a stack-based array. There will be a performance penalty, but it allows for file uploads
    • Added Const::MaxPayload to avoid killing hosts due to massive payloads.
    opened by iroddis 32
  • [ENDPOINT] NEW: Now can use SSL encryption on HTTP endpoint

    [ENDPOINT] NEW: Now can use SSL encryption on HTTP endpoint


    This patch introduces full SSL support for the pistache endpoint. The purpose of this patch is to be able to use SSL encryption without a SSL proxy, which is pretty useful for embedded development.

    It has been tested locally with simple SSL support and certificate connection, my example file is below. I did try to match the coding style of pistache in order to ease the merge, apologies if I missed anything.


    First of all, in order to enable SSL support in the library, one has to compile with PISTACHE_USE_SSL option ON. One can then configure the endpoint to accept / use SSL connections only:

    Http::Endpoint server(addr);
    server.useSSL("./server.crt", "./cert/server.key");

    With that done, all the connections to the server shall now be in HTTPS.

    One can also enable certificate authentication against the server:


    The server will now only accept client connection with a certificate signed with the Certificate Authority passed in the example above.


    Full test file:

    #include <pistache/endpoint.h>
    using namespace Pistache;
    struct HelloHandler : public Http::Handler {
        void onRequest(const Http::Request& request, Http::ResponseWriter writer) {
            writer.send(Http::Code::Ok, "Hello, World!");
    int main(void) {
        Pistache::Address   addr;
        auto opts = Http::Endpoint::options().threads(1);
        addr = Pistache::Address(Pistache::Ipv4::any(), Pistache::Port(9080));
        Http::Endpoint server(addr);
        server.useSSL("./cert/server.crt", "./cert/server.key");
        return 0;

    Compiled with:

    g++ main.cpp -L../pistache/build/src/ -lpistache -I../pistache/include/ -o server -lpthread -lssl -lcrypto

    In order to generate a Certificate Authority and server / client certificate and key, please refer to this gist


    Simple CURL:

    $> curl --cacert CA/rootCA.crt -k                        
    Hello, World!% 

    With CA/rootCA.crt as my root Certificate Authority, used to generate the server certificate. The -k is to ignore the curl error:

    curl: (51) SSL: certificate subject name 'Common Name Test Server' does not match target host name ''

    Since I did not generate a server certificate for

    SSL authentication

    With the following line added in my test file:


    Simple CURL:

    $> curl --cacert CA/rootCA.crt -k
    curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

    With proper client cert & key:

    $> curl --cacert CA/rootCA.crt --cert ./client_cert/client.crt --key client_cert/client.key -k
    Hello, World!%

    Same usage of the -k option as above.

    Verbose output

    $> curl --cacert CA/rootCA.crt --cert ./client_cert/client.crt --key client_cert/client.key -k -v
    *   Trying
    * TCP_NODELAY set
    * Connected to ( port 9080 (#0)
    * ALPN, offering h2
    * ALPN, offering http/1.1
    * successfully set certificate verify locations:
    *   CAfile: CA/rootCA.crt
      CApath: none
    * TLSv1.2 (OUT), TLS handshake, Client hello (1):
    * TLSv1.2 (IN), TLS handshake, Server hello (2):
    * TLSv1.2 (IN), TLS handshake, Certificate (11):
    * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
    * TLSv1.2 (IN), TLS handshake, Request CERT (13):
    * TLSv1.2 (IN), TLS handshake, Server finished (14):
    * TLSv1.2 (OUT), TLS handshake, Certificate (11):
    * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
    * TLSv1.2 (OUT), TLS handshake, CERT verify (15):
    * TLSv1.2 (OUT), TLS change cipher, Client hello (1):
    * TLSv1.2 (OUT), TLS handshake, Finished (20):
    * TLSv1.2 (IN), TLS handshake, Finished (20):
    * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
    * ALPN, server did not agree to a protocol
    * Server certificate:
    *  subject: C=FR; ST=Paris; L=Paris; O=XXX; CN=Common Name Test Server
    *  start date: May 29 15:59:03 2018 GMT
    *  expire date: Oct 11 15:59:03 2019 GMT
    *  issuer: C=FR; ST=Paris; L=Paris; O=XXX; CN=Common Name Root Authority; [email protected]
    *  SSL certificate verify ok.
    > GET /test HTTP/1.1
    > Host:
    > User-Agent: curl/7.60.0
    > Accept: */*
    < HTTP/1.1 200 OK
    < Connection: Keep-Alive
    < Content-Length: 13
    * Connection #0 to host left intact
    Hello, World!% 
    opened by Ne02ptzero 31
  • single async response multithreads

    single async response multithreads

    I am trying to write a c++ pistache server that, on a specific endpoint, has to contact another pistache server. This is the scenario:

    client -> server1 -> server2

    client <- server1 <- server2

    I am having problems waiting for the response in server1 and sending it back to the client asynchronously.

    I share my server1 code to show you how I did implement it.

    void doSmth(const Rest::Request& request, Http::ResponseWriter httpResponse){
            auto resp_srv2 = client.post(addr).body(json).send();    
            [&](Http::Response response) {
            [&](std::exception_ptr exc) {
                PrintException excPrinter;
        Async::Barrier<Http::Response> barrier(resp_srv2);

    In particular this code works only if I set one single thread for the server1. If I use more thread it crash on the first request. Of course the performances are not that good.

    If I try to follow your example, I am able to use more threads. But this has a problem (overflow?) with requests count. On my sever, I can reach around 28k requests sent from the client to server1, and after that it crashes.

    Also, if I do like:

    		    [&](Http::Response response) {
    		    [&](std::exception_ptr exc) {
    		        PrintException excPrinter;

    it does not work well giving back a segmentation fault when the method is called.

    Am I doing something wrong? Please, help me to fix this issue.

    opened by pintauroo 26
  • Upgrade to C++17 and use std::optional

    Upgrade to C++17 and use std::optional

    Fixes #858.

    As per the recommendation by @kiplingw in https://github.com/pistacheio/pistache/issues/858#issuecomment-758279752 this PR upgrades from C++14 to C++17 to take advantage of std::optional.

    enhancement refactor fix in progress 
    opened by jacobbogdanov 26
  • C++17: `std::string_view`, `[[maybe_unused]]`, nested namespaces

    C++17: `std::string_view`, `[[maybe_unused]]`, nested namespaces

    This PR complements #859, and should be merged only after merging that one.

    I recommend reviewing this adding ?w=1 at the end of the URL to ignore whitespace changes.

    Fixes #826, fixes #835.

    fix in progress 
    opened by Tachi107 24
  • Address array and vector storage through .data()

    Address array and vector storage through .data()

    When used like &vec[0], there would be an assert in gnu std lib:

    /usr/include/c++/8/bits/stl_vector.h:932: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = char; _Alloc = std::allocator; std::vector<_Tp, _Alloc>::reference = char&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n < this->size(), true)' failed.

    on the other hand, using .data() is allowed even on empty uninited vectors

    array<> access is modified for consistency.

    opened by win32asm 24
  • Missing round brackets in documentation

    Missing round brackets in documentation

    Hey there!

    Thanks a lot for the documentation. I am currently testing some features and i found a missing bracket. Under "Static file serving":

    if (request.resource() == "/doc" && request.method == Http::Method::Get) {
        Http::serveFile(response, "README.md");

    "request.method" has to be "request.method()"

    Maybe it will help others.

    help wanted doc 
    opened by philippsaul 1
  • pistache server URL is not reachable after remove and add route

    pistache server URL is not reachable after remove and add route

    Issue #1103 : please check pistachio/pistache issue list I just create a UT that include a blocking issue when removing route, just to let people get my PR onto their development box and dig into the problem.

    enhancement fix in progress 
    opened by chorfa007 5
  • [BUG] Listener::~Listener()'s acceptThread.join() deadlocks

    [BUG] Listener::~Listener()'s acceptThread.join() deadlocks

    This may be related to #708 or #761, but I've noticed an issue recently with one of my servers that appears to hang at the acceptThread.join() call here:

            if (isBound())
            if (acceptThread.joinable())
            if (listen_fd >= 0)
                listen_fd = -1;

    This appears to happen occasionally on destruction via Pistache::Http::Endpoint::~Endpoint(). The acceptThread.join() is just a wrapper for std::thread::join(), of course.

    I have two separate core dumps of the same process. One before I asked it to terminate gracefully via SIGTERM signal and the other after issuing the signal. In both I see a Pistache listener thread that appears to be hanging in OpenSSL's BIO_read(). I'm pretty sure this is the problem because in the coredump post SIGTERM after all other threads, besides main, have exited, still remains:

    #0  __GI___libc_read (nbytes=5, buf=0x7ffb94008da3, fd=4) at ../sysdeps/unix/sysv/linux/read.c:26
            sc_ret = -512
            sc_cancel_oldtype = 0
            sc_ret = <optimized out>
    #1  __GI___libc_read (fd=4, buf=0x7ffb94008da3, nbytes=5) at ../sysdeps/unix/sysv/linux/read.c:24
    #2  0x00007ffb9d5f0ddd in  () at /lib/x86_64-linux-gnu/libcrypto.so.3
    #3  0x00007ffb9d5e12eb in  () at /lib/x86_64-linux-gnu/libcrypto.so.3
    #4  0x00007ffb9d5e42e5 in  () at /lib/x86_64-linux-gnu/libcrypto.so.3
    #5  0x00007ffb9d5e4467 in BIO_read () at /lib/x86_64-linux-gnu/libcrypto.so.3
    #6  0x00007ffb9cba934c in  () at /lib/x86_64-linux-gnu/libssl.so.3
    #7  0x00007ffb9cbaaf19 in  () at /lib/x86_64-linux-gnu/libssl.so.3
    #8  0x00007ffb9cbbcb36 in  () at /lib/x86_64-linux-gnu/libssl.so.3
    #9  0x00007ffb9cbbe608 in  () at /lib/x86_64-linux-gnu/libssl.so.3
    #10 0x00007ffb9d4aeb2d in Pistache::Tcp::Listener::handleNewConnection() (this=0x7fff974787f8) at ../src/server/listener.cc:481
            ssl_data = 0x7ffb94011320
                      peer_addr = {ss_family = 2, __ss_padding = "\302v<\331KF\000\000\000\000\000\000\000\000@FǙ\373\177\000\000\364M\362\234\373\177", '\000' <repeats 18 times>, "\240B\033\235\373\177\000\000\200\020\000\224\373\177\000\000\200#\000\000\000\000\000\000HiǛ\373\177\000\000\000\000\000\000\000\000\000\001\000\020\000\000\000\000\000\000\000@G\231\373\177", '\000' <repeats 11 times>, "\020\200\000\000\000\000", __ss_align = 4096}
            client_fd = 4
            ssl = 0x0
            peer = std::shared_ptr<Pistache::Tcp::Peer> (use count -1811939008, weak count 32762) = {get() = 0x7ffb94023bf0}
            peer_alias = <optimized out>
    #11 0x00007ffb9d4aeef3 in Pistache::Tcp::Listener::run() (this=0x7fff974787f8) at ../src/server/listener.cc:367
            fd = <optimized out>
            event = @0x7ffb94001230: {flags = {val = Pistache::Polling::NotifyOn::Read}, tag = {value_ = 5}}
            __for_range = std::vector of length 1, capacity 1 = {{flags = {val = Pistache::Polling::NotifyOn::Read}, tag = {value_ = 5}}}
            events = std::vector of length 1, capacity 1 = {{flags = {val = Pistache::Polling::NotifyOn::Read}, tag = {value_ = 5}}}
            ready_fds = <optimized out>
    #12 0x00007ffb9d1b42b3 in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
    #13 0x00007ffb9cf24b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
            ret = <optimized out>
            pd = <optimized out>
                          unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140735731431920, 1193485945046415927, 140718627063360, 0, 140718646642768, 14073573143227--Type <RET> for more, q to quit, c to continue without paging--c
    2, -1195940266122823113, -1195946767574910409}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
            not_first_call = <optimized out>
    #14 0x00007ffb9cfb6a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

    The acceptThread.join() is probably deadlocked waiting for that listener thread to finish what it's doing. The ../src/server/listener.cc:481 is the call to SSL_accept(ssl_data). So the handshake appears to hang every now and then, rather than timing out.

    This then raises the question of what is making SSL_accept(ssl_data) hang indefinitely? This may have always been a problem, but perhaps something in my network topology my server sits in recently made this problem become evident. Perhaps the workaround is to specify a timeout?

    This person's issue seems very similar to mine in that as soon as the hang occurs the server will not accept any new connections.

    bug help wanted 
    opened by kiplingw 0
  • Unable to parse Accept Header of Specific format

    Unable to parse Accept Header of Specific format

    Hi, I'm unable to get any request coming from one specific client and upon using wireshark, I was able to find why on_request never got hit. Pistache Automatically sent the following response HTTP/1.1 415 Unsupported Media Type\r\n Further Explanation attached to it was : "Malformed Media Type, expected a '/' after the top type"

    The Accept Tag of Request is as follows: Accept: text/html, image/gif, image/jpeg, *; q=.2, * / *; q=.2\r\n (Edit: I myself gave space in * / * , as it italicized the query)

    Upon analyzing, void Accept::parseRaw(const char* str, size_t len) in http_header.cc is handling eof and ',' in while conditions and not semicolon ';' whereas the Accept has semicolons as well along with q=.2

    Furthermore it seems that it is going in mime.cc and on this check if (!match_literal('/', cursor)) , it raised the error , and just a thought, can it be caused because of the single '*' after jpeg?

    Kindly, can you guide me what can be the problem and how can it be solved? I might not be able to change the Accept tag as it's Pre/By Default defined in a Cisco UCCX Telephony setup

    opened by danishmarif 2
  • Add/remove routes at runtime

    Add/remove routes at runtime

    I started writing a thread-safe wrapper for Router / Private::RouterHandler to support adding and removing routes dynamically, when I saw in the RouterHandler comments:

                 * Used for mutable router. Useful if it is required to
                 * add/remove routes at runtime.
                 * \param[in] router Pointer to a (mutable) router.
                explicit RouterHandler(std::shared_ptr<Rest::Router> router);

    I wondered how this might be done safely, once the server is running? Can it only be done when processing a request on a single-threaded server?

    opened by arghness 3
  • How do I make an endpoint with a downloadable file in response?

    How do I make an endpoint with a downloadable file in response?

    I'm trying to load a .csv file (Content-Disposition: attachment) when accessing the endpoint, but the tools I found for this (response.send() and serveFile() do not provide this capability.) How can I do it?

    opened by wjnao 4
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 Jan 4, 2023
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 29, 2022
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.7k Jan 9, 2023
Cetus is a high performance, stable, protocol aware proxy for MySQL Group Replication.

Introduction Cetus is a high performance, stable, protocol aware proxy for MySQL Group Replication. Getting started 1. Prerequisites cmake gcc glib2-d

null 37 Sep 19, 2022
CppCMS - High Performance C++ Web Framework

CppCMS - High Performance C++ Web Framework What is CppCMS? CppCMS is a Free High Performance Web Development Framework (not a CMS) aimed at Rapid Web

Artyom Beilis 375 Dec 25, 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 Dec 17, 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 22, 2022
a very based, minimal, and flexible static site generator written in pure C89 with no external deps.

based-ssg is a very based, minimal, and flexible static site generator written in pure C89 with no external deps.

null 15 Dec 22, 2022
A WebAssembly interpreter written in C for demonstration.

wasmc 中文文档 A WebAssembly interpreter written in C for demonstration. This repository implements a WebAssembly interpreter. It is written to clarify ho

湮远 63 Dec 23, 2022
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
Experimental and Comparative Performance Measurements of High Performance Computing Based on OpenMP and MPI

High-Performance-Computing-Experiments Experimental and Comparative Performance Measurements of High Performance Computing Based on OpenMP and MPI 实验结

Jiang Lu 1 Nov 27, 2021
Microsoft Cognitive Toolkit (CNTK), an open source deep-learning toolkit

CNTK Chat Windows build status Linux build status The Microsoft Cognitive Toolkit (https://cntk.ai) is a unified deep learning toolkit that describes

Microsoft 17.3k Dec 23, 2022
Lite.AI.ToolKit 🚀🚀🌟: A lite C++ toolkit of awesome AI models such as RobustVideoMatting🔥, YOLOX🔥, YOLOP🔥 etc.

Lite.AI.ToolKit ?? ?? ?? : A lite C++ toolkit of awesome AI models which contains 70+ models now. It's a collection of personal interests. Such as RVM, YOLOX, YOLOP, YOLOR, YoloV5, DeepLabV3, ArcFace, etc.

DefTruth 2.4k Jan 9, 2023
Zenotech 6 Oct 21, 2022
Insight Toolkit (ITK) is an open-source, cross-platform toolkit for N-dimensional scientific image processing, segmentation, and registration

ITK: The Insight Toolkit C++ Python Linux macOS Windows Linux (Code coverage) Links Homepage Download Discussion Software Guide Help Examples Issue tr

Insight Software Consortium 1.1k Dec 26, 2022
Microsoft Cognitive Toolkit (CNTK), an open source deep-learning toolkit

The Microsoft Cognitive Toolkit is a unified deep learning toolkit that describes neural networks as a series of computational steps via a directed graph.

Microsoft 17.3k Jan 6, 2023
An eventing framework for building high performance and high scalability systems in C.

NOTE: THIS PROJECT HAS BEEN DEPRECATED AND IS NO LONGER ACTIVELY MAINTAINED As of 2019-03-08, this project will no longer be maintained and will be ar

Facebook Archive 1.7k Dec 14, 2022
OceanBase is an enterprise distributed relational database with high availability, high performance, horizontal scalability, and compatibility with SQL standards.

What is OceanBase database OceanBase Database is a native distributed relational database. It is developed entirely by Alibaba and Ant Group. OceanBas

OceanBase 5.1k Jan 4, 2023