Short term goals for HTTP server

Now that the original maintainers were graciously willing to allow me to help with the vision and execution of this project, I wanted to talk about some of the things that I am thinking of for the project. As I helped with the HTTP server, a lot of my focus is geared around it's implementation and improving upon it's implementation. It was a great 1.0 version, but it definitely has a long way to go before I consider it to be production ready.

I wanted to start a discussion around where it's current short comings are that I want to fix relatively quickly and some short term goals I think would be nice to have. I would like feedback on these items and would love to hear if you think there is a better idea we can go down.

Quick fixes that I want to wrap into what I think should go into a 1.2 release:

- [ ] SSL support. Security should always be the focus, and I want to to be a default config. I'm thinking of having a flag similar to `-IWantNoSecurity` or something where the operator has to opt in. Let's Encrypt as an SSL provider has made free, trusted certificates so readily available that I would like to make sure we have high standards for security. Until I joined, the original maintenance and development team has had high standards, I want to continue that legacy.
- [ ] Authentication for the API for adding items to the cache. Since security is important, we don't want an attacker to be able to just overload a public cache and crash it repeatedly. I currently don't think reads should be authenticated at this point, but I'd be more than open it in a later version. Currently I'm thinking of a master API key that can be set when the server is initialised. MVP on this would be a CLI flag.
- [x] CLI deliverable for release. It would be good to have separate binary downloadables for the HTTP server when we release a new version. That way operators/engineers can quickly get up and running without needing to compile themselves.
- [ ] Deployment manifests? This one I'm on the fence about. Full disclosure, my employer is invested into the core project maintenance with Kubernetes and Cloud Foundry. I personally do not have a role in that maintenance, but I do like consuming both projects for personal use. I'm thinking of adding reference deployment manifests for both Cloud Foundry and Kubernetes, so if a user does have the code base, they can just push the HTTP server with some defaults. While my focus with this idea is to promote the available of this awesome project, it's definitely not a priority. I'm okay with pushing this off til someone asks for it or one of us decides it's more important than it is now.

Would love to get some feedback on these items. I haven't started the work yet but would like to soon.