http_listener in the "experimental" namespace

[TalibKweli]

Hi, I've recently been updating a C++ application that needs an HTTP server to be integrated. After doing some prototyping the http_listener seems to fit exactly with what we need, but I've noticed it is in the "experimental" namespace. How "experimental" is the http_listener? Is it mature enough to use in a production system?

Thanks

[gfreewind]

I also care about it. Because I want to use cpprestsdk to implement REST server.

[ras0219-msft]

The http_listener has not undergone the same level of testing rigor as our http_client. We've primarily implemented it in order to support OAuth2 client flows that require a redirection (so you can stand up a local server), however many users have found it quite useful on its own -- including contributing https support.

If you're experimenting on a local project, or building something for internal use, it should be perfectly serviceable. However, public-facing secure webservers are very challenging pieces of software to write correctly, and we would not feel comfortable with marking our http_listener as being production-ready in that way without significantly more testing (including fuzzing and perhaps even proofs of correctness).

If you are looking to build a production quality service that needs to defend against malicious attackers, I highly recommend using one of the large, industry-vetted software packages like IIS, Apache, or Nginx, then building a plugin.

[cmazakas]

I certainly hope it becomes production-ready sooner rather than later. cpprestsdk is amazing for service-oriented architectures and it'd be nice to see the framework support for both consuming and sending data.

[mobileben]

@ras0219-msft just out of curiosity, is there some form of roadmap towards making it production ready?

For example, tests to be done, features to implement if needed to make it more robust to server as a public-facing secure server. You could perhaps then get a few people here to attack those tasks and bring it closer to production and then eventually (hopefully) production ready code.

One of the nice aspects for potentially using cpprestsdk is that (at least for my usage) it allows me to write client and server code using the same library. I'm using this in the context of potentially being the basis for a game server.

[cmazakas]

Well to be fair, cpprestsdk does seem to be more focused on back-end architectures emphasizing multiple services. Tools like Apache and Nginx are well-established and well-tested public-facing servers.

cpprestsdk can handle being behind those kinds of servers pretty well but to say it's ready to face the same onslaught as Apache, etc. is probably what they're not comfortable with.

[mobileben]

Yes, that is indeed fair. Probably a better stated inquiry would be is there a roadmap for ditching the experimental namespace with recommendations that this be not public facing, but robust enough for production backend services behind Apache/Nginx/etc.

[brat1105]

We're also looking at using the http_listener as an embedded REST server. Is the list of known issues/errors associated with the http_listener?

[ss430]

Exactly my thoughts. We are looking at using the HTTP listener on a project of ours which is going to be for production use. At the moment we envision an NGINX web server which will be the public facing component, which then redirects the incoming requests to the experimental HTTP listener. Is this an acceptable solution to use the experimental HTTP listener for a project of ours?

[banzr]

I also ask MSFT to take the steps to bring the HTTP Listener out of Experimental. It would be very useful for so many projects.