Pistache is a modern and elegant HTTP and REST framework for C++




autopkgtest REUSE status

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.


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

A comparison of Pistache to other C++ RESTful APIs was created by guteksan and is available here.


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 (@octal). He continues to contribute to the maintainence and development of Pistache, supported by a team of volunteers. The maintainers can be reached in #pistache on Libera.Chat (ircs://irc.libera.chat:6697). Please come and join us!

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


The version of the library's public interface (ABI) is not the same as the release version, but we choose to always guarantee that the major release version and the soname version will match. 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 not supported in Meson so we made do without it by setting the SONAME directly.

When Pistache is installed it will normally ship:

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

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

  • libpistache.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 when you make incompatible API or ABI changes. The minor version should be incremented when you add functionality in a backwards compatible manner. The patch version should be incremented when you make backwards compatible bug fixes. This can be done by modifying version.txt accordingly. Also remember to always update the commit date in the aformentioned file.

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.

  • amd64
  • arm64
  • armhf
  • i386
  • ppc64el
  • riscv64
  • 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 Meson, you just need to add dependency('libpistache') as a dependency for your executable.

    meson_version: '>=0.55.0'

    sources: 'main.cpp',
    dependencies: dependency('libpistache')

If you want to build the library from source in case the dependency is not found on the system, you can add this repository as a submodule in the subprojects directory of your project, and edit the dependency() call as follows:

dependency('libpistache', fallback: 'pistache')

If you're using a Meson version older than 0.55.0 you'll have to use the "older" syntax for dependency():

dependency('libpistache', fallback: ['pistache', 'pistache_dep'])

Lastly, if you'd like to build the fallback as a static library you can specify it with the default_options keyword:

dependency('libpistache', fallback: 'pistache', default_options: 'default_library=static')


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

cmake_minimum_required(VERSION 3.6)

pkg_check_modules(Pistache REQUIRED IMPORTED_TARGET libpistache)

add_executable(${PROJECT_NAME} main.cpp)
target_link_libraries(${PROJECT_NAME} PkgConfig::Pistache)


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/pistacheio/pistache.git

Now, compile the sources:

$ cd pistache
$ meson setup build \
    --buildtype=release \
$ meson compile -C build
$ meson install -C build

Optionally, you can also run the tests:

$ meson test -C build

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 Meson options:

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


Hello World (server)

(Pistache::Address("*:9080")); }">
#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() {

Project status

Pistache hasn't yet hit the 1.0 release. This means that the project is unstable but not unusable. In fact, most of the code is production ready; you can use Pistache to develop a RESTful API without issues, but the HTTP client has a few issues in it that make it buggy.

* While most code uses modern C++, Pistache makes use of some Linux-specific APIs where the standard library doesn't provide alternatives, and works only on that OS. See #6 for details. If you know how to help, please contribute a PR to add support for your desired platform :)

  • 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\[email protected]Ǚ\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\[email protected]\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
The C++ REST SDK is a Microsoft project for cloud-based client-server communication in native code using a modern asynchronous C++ API design. This project aims to help C++ developers connect to and interact with services.

Welcome! The C++ REST SDK is a Microsoft project for cloud-based client-server communication in native code using a modern asynchronous C++ API design

Microsoft 7.2k Jan 8, 2023
A high-performance REST Toolkit written in C++

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

null 2.8k Dec 29, 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.5k Dec 31, 2022
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 17 Oct 15, 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
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
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 809 Dec 19, 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
C library to create simple HTTP servers and Web Applications.

Onion http server library Travis status Coverity status Onion is a C library to create simple HTTP servers and Web Applications. master the developmen

David Moreno Montero 1.9k Dec 31, 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
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 166 Dec 5, 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++ 6k Jan 4, 2023
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 950 Dec 24, 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 Jan 8, 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
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é 249 Dec 22, 2022
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.8k Jan 7, 2023