Hi Billy, thanks for the review. Of course all of these points are very valid--I guess I should have pointed out the draft status of this PR better, sorry about that.

I take it you are generally interested in this?

As of now, the client component can optionally be built with Botan instead of OpenSSL, OpenSSL remaining the default.
Initially our goal was to allow users getting rid of OpenSSL entirely. Unfortunately, OpenSSL will still be required for the http listener component, as the Botan SSL stream cannot (yet) be used for this side.

I should have pointed out the draft status of this PR better

Nah, it's fine! We don't check up on PRs here very often, so given that I was over here I wanted to give some feedback in case it'd be helpful.

I take it you are generally interested in this?

Not particularly. The entire cpprestsdk project at this time is kinda in maintenance mode. The usual arrangement for PRs though is for people to contribute things that they care about that the original authors might not care about.

That's why I'm specifically looking for an azure-pipelines.yaml change if you want us to accept this because we super don't know what we're doing when it comes to a different SSL backend.

OpenSSL will still be required for the http listener component

The listener component basically exists to be the unit test harness for the client, so that sounds okay.

The listener component basically exists to be the unit test harness for the client, so that sounds okay.

Well that's a case in point where many users care about something the original authors don't. 🙂

We're very much using http_listener for real, with and without TLS, in a number of different platform/scenarios. It has been perfectly functional and, with PRs over the last year or so, has had enough attention that it could quite reasonably be moved out of the namespace experimental IMO. I'd like to contribute the similarly-styled ws_listener we built and which a couple of other users have also reported trying out successfully. I've held back due to (a) incomplete tests, and (b) ideally wanting to refactor some of the things that are in the websocket::client namespace up a layer, since they make sense for both client and listener, and finally therefore because (c) I'm not clear what the level of interest from maintainers is/how high a bar needs to be passed, to invest into doing (a) and (b).

Sorry for jumping on the Botan PR!

We're very much using http_listener for real, with and without TLS, in a number of different platform/scenarios.

Please be advised that it isn't suitable for use in production scenarios -- notably, it has not been security audited, fuzz tested, or otherwise hardened for reasonably safe use in environments wherein the whole internet is attacking you.

it could quite reasonably be moved out of the namespace experimental

We would need to think it was safe to use as a production web server to do that, and we do not believe that is true at this time. (In fact much the opposite -- thread sanitizer has found a number of scary issues that likely require a rewrite of most / all of the listener if we wanted to harden it)

Please be advised that it isn't suitable for use in production scenarios -- notably, it has not been security audited, fuzz tested, or otherwise hardened for reasonably safe use in environments wherein the whole internet is attacking you.

Thanks, @BillyONeal, that's a sensible note of caution. We have done some regular pen testing, but I should have clarified we are not yet operating in internet environments.

In fact much the opposite -- thread sanitizer has found a number of scary issues that likely require a rewrite of most / all of the listener if we wanted to harden it

Would it be worth throwing these up as an issue - even if it isn't actively being pursued - to allow users to see these results without having to develop these tests, or sharing the test set up, so that users can easily reproduce the results?

So, what would be the interest/benchmark for adding web::websockets::experimental::listener::ws_listener using websocketpp back-end?

Would it be worth throwing these up as an issue - even if it isn't actively being pursued - to allow users to see these results without having to develop these tests, or sharing the test set up, so that users can easily reproduce the results?

All I did was run the unit tests under tsan. The most common error was assuming multiple threads could concurrently touch shared_ptrs. I fixed a few obvious ones as part of onboarding to Azure Pipelines because without that the tests were too flaky to be useful.

Ok, thanks a lot to both of you for the feedback.

With that, and with what we have learned from playing around with it more on our side, it has become clear that a larger change than I originally imagined would be required for a clean implementation that works on all platforms. It is probably not desirable for the cpprestsdk project to maintain these changes. Closing.