`with_tls` panics when given incorrect information

[lpil]

Hello!

This function panics, which a library should never do, especially not for simple configuration.

It is also not documented what the arguments are, or what happens when they are incorrect.

It seems strange to me that this API forces the programmer to keep the data on the file system, instead of passing it in as an argument like normal Gleam code.

Thanks,
Louis

[rawhat]

I don't exactly recall my logic for having this panic immediately other than that it seemed nicer than the application supervisor going bananas if the certificates weren't valid. However, I do that for glisten, so it's probably fine.

We've talked about using a non-file API for TLS before. Do you have examples of other languages / libraries that do this? I've been mucking around with the erlang one and am struggling a bit. I want to make sure I understand what all I need to do.

For reference, as far as I can tell Bandit only allows the same options that I'm providing. I'm not totally sure about cowboy (or ranch, I guess), but it seems to mostly just pass things through. So it's possible it's supported there.

I'm going to keep plugging away at this, but it's not particularly straightforward. Removing the panic would be, so if that's an acceptable middle-ground, I'm also happy to do that quickly.

[lpil]

Do you have examples of other languages / libraries that do this?

Rust (rustls), Go (crypto/tls), C++ (OpenSSL), Java, C#, NodeJS, Zig, Ruby (OpenSSL), PHP. It also looks like Erlang's ssl supports it too.

The only one I could find that doesn't is the Python stdlib, but maybe there's an API that doesn't mandate a filesystem roundtrip that I could not find.

application supervisor going bananas if the certificates weren't valid.

It wouldn't do that, the init phase is for operations that must succeed. That said, I think both behaviours are not ideal, rather it would be up to the programmer to be responsible for loading data from the environment (if required).