7 ms·

Awesome! I've used https://www.gnu.org/software/libmicrohttpd/ https://www.gnu.org/software/libmicrohttpd/ in the past (for fun stuff I was building to learn C)

Awesome! I've used https://www.gnu.org/software/libmicrohttpd/ https://www.gnu.org/software/libmicrohttpd/ in the past (for fun stuff I was building to learn C), will try this out instead. But.. > Only HTTPS connections allowed Seems a bit painful. HTTPS on the webserver itself is a fair bit more painful to setup and administer than HTTPS in your reverse proxy / loadbalancer (I prefer nginx). Web servers should support plain HTTP.

bubblesorting 11y ago
I'm not trying to antagonize here, but what do you find so bad? I would call it a little bit more painful; three lines to add to an nginx config, along with generating the cert. Maybe 10 minutes of work? Thirty if you're getting a CA to sign your cert for you. I could see pain if you need to wait for finance to approve, or if you're trying to get domains validated on behalf of a customer. And I suppose it adds another setup step to wireshark (if you need to debug neat bugs), but that's a set-it-up-once-and-forget-about-it thing.
- Canada 11y ago
  It's a scalability problem. If you have many web servers behind a reverse proxy that takes care of TLS it's often pointless to waste processing power on encryption in between.
  - anthony_franco 11y ago
    Yep. And on top of that a reverse proxy is unable to inspect the requests to route them smartly (based on path, cookies, etc.).
    - Canada 11y ago
      Well, the reverse proxy would have made the backend request itself, so it's free to inspect or modify anything.
jvink 11y ago
You can turn off TLS on Kore. $ make BENCHMARK=1 It is not a run time option by design, but it is there. I want Kore to have sane defaults for getting up and running. That means TLS (1.2 default by only), no RSA based key exchanges, AEAD ciphers preferred and the likes. edit: spelling
- crest 11y ago
  RSA with DHE or ECDHE is a sane handshake. I would avoid DSA and ECDSA based key exchanges because they fail catastrophically with bad random number generators. For most APIs session caching is more important than a faster initial handshake. The HTTPS only choice would annoy me a lot because I run most HTTPS services in behind a reverse proxy in a FreeBSD jail on the same host. HA proxy and nginx are still superior to most applications in regard to reliable TLS termination. Using HTTPS by default a the right choice for a new project but offering no HTTP support (outside of a benchmark) patronizes the user. All in all this looks like a nice way to export C APIs through HTTPS.
  - jvink 11y ago
    Thanks. I agree the BENCHMARK build option is a bit confusing. I might end up renaming it altogether.
    - jvink 11y ago
      For sanity sake, this build option is now NOTLS.
mitchi 11y ago
Everytime something like this comes out, I think the following : Wouldn't it be great if I could develop and debug this under Windows with VS and deploy my release with Linux. The network libraries are always Linux(and family) only.
- provost 11y ago
  I don't see a reason why you can't make it cross-platform, with a bit of effort: https://github.com/jorisvink/kore https://github.com/jorisvink/kore

bubblesorting 11y ago

I'm not trying to antagonize here, but what do you find so bad? I would call it a little bit more painful; three lines to add to an nginx config, along with generating the cert. Maybe 10 minutes of work? Thirty if you're getting a CA to sign your cert for you. I could see pain if you need to wait for finance to approve, or if you're trying to get domains validated on behalf of a customer. And I suppose it adds another setup step to wireshark (if you need to debug neat bugs), but that's a set-it-up-once-and-forget-about-it thing.

Canada 11y ago
It's a scalability problem. If you have many web servers behind a reverse proxy that takes care of TLS it's often pointless to waste processing power on encryption in between.
- anthony_franco 11y ago
  Yep. And on top of that a reverse proxy is unable to inspect the requests to route them smartly (based on path, cookies, etc.).
  - Canada 11y ago
    Well, the reverse proxy would have made the backend request itself, so it's free to inspect or modify anything.

jvink 11y ago

You can turn off TLS on Kore. $ make BENCHMARK=1 It is not a run time option by design, but it is there. I want Kore to have sane defaults for getting up and running. That means TLS (1.2 default by only), no RSA based key exchanges, AEAD ciphers preferred and the likes. edit: spelling

crest 11y ago
RSA with DHE or ECDHE is a sane handshake. I would avoid DSA and ECDSA based key exchanges because they fail catastrophically with bad random number generators. For most APIs session caching is more important than a faster initial handshake. The HTTPS only choice would annoy me a lot because I run most HTTPS services in behind a reverse proxy in a FreeBSD jail on the same host. HA proxy and nginx are still superior to most applications in regard to reliable TLS termination. Using HTTPS by default a the right choice for a new project but offering no HTTP support (outside of a benchmark) patronizes the user. All in all this looks like a nice way to export C APIs through HTTPS.
- jvink 11y ago
  Thanks. I agree the BENCHMARK build option is a bit confusing. I might end up renaming it altogether.
  - jvink 11y ago
    For sanity sake, this build option is now NOTLS.

mitchi 11y ago

Everytime something like this comes out, I think the following : Wouldn't it be great if I could develop and debug this under Windows with VS and deploy my release with Linux. The network libraries are always Linux(and family) only.

provost 11y ago
I don't see a reason why you can't make it cross-platform, with a bit of effort: https://github.com/jorisvink/kore https://github.com/jorisvink/kore