[llvm-dev] HTTP library in LLVM

Jonas Devlieghere via llvm-dev llvm-dev at lists.llvm.org
Mon Aug 31 23:29:18 PDT 2020


On Mon, Aug 31, 2020 at 23:22 Tobias Hieta <tobias at plexapp.com> wrote:

> Hello,
>
>
>
> I have only negative experiences with cpp-netlib - I would not recommend
> it.


Can you elaborate on those negative experiences? I think that would be
helpful in comparing it to the other alternatives.

>
>
>
> If the discussion was around only the client part I think libcURL
>
> would be the best option since it's available everywhere and is a well
>
> maintained library. But as you mention it's only the client part.


Yeah, I thought the same going through the list.

>

>
> We use pion (https://github.com/splunk/pion) to build a HTTP server
>
> interface, but since it seems pretty unmaintained I am not sure I
>
> would recommend it.
>
>
>
> I have heard good things about https://github.com/matt-42/lithium/ but
>
> have no direct experience of using / building it.
>
>
>
> Thanks,
>
> Tobias
>
>
>
> On Tue, Sep 1, 2020 at 2:22 AM Petr Hosek via llvm-dev
>
> <llvm-dev at lists.llvm.org> wrote:
>
> >
>
> > These are the ones I found so far:
>
> >
>
> > * [libmicrohttpd](https://www.gnu.org/software/libmicrohttpd/) is used
> by elfutils' debuginfod, but it's LGPL licensed.
>
> > * [libcURL](https://curl.haxx.se/libcurl/) would be an option for the
> client, but we'd need a different library for the server.
>
> > * [libhttp](https://github.com/lammertb/libhttp) is another MIT
> licensed library that could be a fit, but it seems bigger and more
> featureful than httplib.
>
> > * [cpprestsdk](https://github.com/microsoft/cpprestsdk) has a lot of
> extra features we don't need, like websockets.
>
> > * [pistache](https://github.com/oktal/pistache) similarly has
> additional features and dependencies that are likely unnecessary.
>
> > * [crow](https://github.com/ipkn/crow) is similar to cpprestsdk and
> pistache, it depends on Boost.
>
> > * [cpp-netlib](https://github.com/cpp-netlib/cpp-netlib) looks nice but
> depends on Boost.
>
> > * [proxygen](https://github.com/facebook/proxygen) is also nice but has
> a lot of dependencies including Boost.
>
> >
>
> > On Mon, Aug 31, 2020 at 4:48 PM Jonas Devlieghere <jonas at devlieghere.com>
> wrote:
>
> >>
>
> >> On Mon, Aug 31, 2020 at 4:38 PM Petr Hosek via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> >>>
>
> >>> There are several options, I've looked at couple of them and the one I
> like the most so far is https://github.com/yhirose/cpp-httplib for a few
> reasons:
>
> >>>
>
> >>> * It's MIT licensed.
>
> >>> * It supports Linux, macOS and Windows (and presumably other
> platforms).
>
> >>> * It doesn't have any dependencies, it can optionally use zlib and
> OpenSSL.
>
> >>> * It's a modern C++11 implementation, the entire library is a single
> header.
>
> >>
>
> >>
>
> >> This looks appealing indeed. Out of curiosity, what are the other
> alternatives you considered?
>
> >>
>
> >>>
>
> >>>
>
> >>> On Mon, Aug 31, 2020 at 4:31 PM Eric Christopher <echristo at gmail.com>
> wrote:
>
> >>>>
>
> >>>> +LLDB Dev as well for visibility. +Pavel Labath since he and I have
> talked about such things.
>
> >>>>
>
> >>>> On Mon, Aug 31, 2020 at 7:26 PM David Blaikie <dblaikie at gmail.com>
> wrote:
>
> >>>>>
>
> >>>>> [+debug info folks, just as FYI - since the immediate question's
> more about 3rd party library deps than the nuances of DWARF, etc]
>
> >>>>>
>
> >>>>> I'd imagine avoiding writing such a thing from scratch would be
> desirable, but that the decision might depend somewhat on what libraries
> out there you/we would consider including, what their licenses and further
> dependencies are.
>
> >>>>>
>
> >>>>> On Mon, Aug 31, 2020 at 4:22 PM Petr Hosek via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> >>>>>>
>
> >>>>>> We're considering implementing [debuginfod](
> https://sourceware.org/elfutils/Debuginfod.html) library in LLVM.
> Initially, we'd like to start with the client implementation, which would
> enable debuginfod support in tools like llvm-symbolizer, but later we'd
> also like to provide LLVM-based debuginfod server implementation.
>
> >>>>>>
>
> >>>>>> debuginfod uses HTTP and so we need an HTTP library, ideally one
> that supports both client and server.
>
> >>>>>>
>
> >>>>>> The question is, would it be acceptable to use an existing C++ HTTP
> library or would it be preferred to implement an HTTP library in LLVM from
> scratch?
>
> >>>>>> _______________________________________________
>
> >>>>>> LLVM Developers mailing list
>
> >>>>>> llvm-dev at lists.llvm.org
>
> >>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> >>>
>
> >>> _______________________________________________
>
> >>> LLVM Developers mailing list
>
> >>> llvm-dev at lists.llvm.org
>
> >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> >
>
> > _______________________________________________
>
> > LLVM Developers mailing list
>
> > llvm-dev at lists.llvm.org
>
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> --
Sent from my iPhone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200831/8adce2fa/attachment.html>


More information about the llvm-dev mailing list