Earlier quoted context omitted.
Is there more to the philosophy of why caddy exists? I am trying to jump into a few open source projects to hone my programming skills and I have a harder time comprehending things if I don't know what was the overall intention of the authors.
One of the big selling points of Caddy for me is that you can reconfigure it "live" without restarting the server. This is great for if you want to be able to do zero-downtime deploys of new applications behind a proxy server or similar.
static-server: an HTTP server in Go for static content
41–50 of 67 posts
Re: static-server: an HTTP server in Go for static content
#42These are fun to make. I've done it several times. :) That is why I wrote Caddy: $ caddy file-server It does templates, TLS, and other production things really easily from the command line too, including automatically getting certificates: $ caddy file-server --domain example.com Done! I think projects like static-server are wonderful learning examples of how to get Useful Things done in Go.
I know I can write it in JSON, but IMO the greatest appeal of Caddy is its simple and easy-to-read Caddyfile!
Re: static-server: an HTTP server in Go for static content
#43These are fun to make. I've done it several times. :) That is why I wrote Caddy: $ caddy file-server It does templates, TLS, and other production things really easily from the command line too, including automatically getting certificates: $ caddy file-server --domain example.com Done! I think projects like static-server are wonderful learning examples of how to get Useful Things done in Go.
Is there more to the philosophy of why caddy exists? I am trying to jump into a few open source projects to hone my programming skills and I have a harder time comprehending things if I don't know what was the overall intention of the authors.
It seems like in every thread about web servers, the developers are in here peddling their wares, and the disciples pour in with endless praise.
It's another product with insane footgun defaults (the admin API on localhost) in a sea of mature alternatives. That's all I need to know.
I don't mean to insult anyone's hard work but in the words of Josh Baskin, "I don't get it."
Re: static-server: an HTTP server in Go for static content
#44Earlier quoted context omitted.
One of the big selling points of Caddy for me is that you can reconfigure it "live" without restarting the server. This is great for if you want to be able to do zero-downtime deploys of new applications behind a proxy server or similar.
I think nginx does that too; if you send it a hup signal, it will reload the config.
Re: static-server: an HTTP server in Go for static content
#45Out of curiosity, are there alternatives to this that are already well established or distributed? For example, something you'd get in debian linux?
Re: static-server: an HTTP server in Go for static content
#46Earlier quoted context omitted.
> I know you’ll say “It’s just a static server, meant for serving static stuff” but it will be indexed by pkg.go.dev, people will use this outside your intent. While true, I don't think the author should refrain from making code available based on the potential negatives from others using code they didn't even bother to read the documentation for.
You’re right, however, due to the nature of the go ecosystem, someone will use it - host their react app with it - and expose an endpoint that could shutdown their server. I think that warrants being called out for.
Need I be called out, now?
Re: static-server: an HTTP server in Go for static content
#47Awesome. There is a very surreal joy in building such standalone tools even just for learning. I have been working on a kitchen sync style "chat" app to experiment with new ideas (like integration with X/y/z). I just need to muster the courage to publish it!
I say publish your work. Chances are, no one will care and you have a nice backup of your code. And if someone does find it useful, then great!
Re: static-server: an HTTP server in Go for static content
#48While I love Go, have we gotten this lazy that we need a package for this? Go does this in 3 lines minimum, like you describe in your blogpost. However, in your package you expose the ability to kill your server [0] without any security. That’s a huge vulnerability. I know you’ll say “It’s just a static server, meant for serving static stuff” but it will be indexed by pkg.go.dev, people will use this outside your int…
Re: static-server: an HTTP server in Go for static content
#49These are fun to make. I've done it several times. :) That is why I wrote Caddy: $ caddy file-server It does templates, TLS, and other production things really easily from the command line too, including automatically getting certificates: $ caddy file-server --domain example.com Done! I think projects like static-server are wonderful learning examples of how to get Useful Things done in Go.
Re: static-server: an HTTP server in Go for static content
#50Earlier quoted context omitted.
Is there more to the philosophy of why caddy exists? I am trying to jump into a few open source projects to hone my programming skills and I have a harder time comprehending things if I don't know what was the overall intention of the authors.
Caddy 1 was created because I needed a quick and easy web server for a lot of my projects. Caddy 2 was created when I got serious about it, and we had governments and enterprises starting to rely on the project. Now we exist because we advocate for (and deliver!) HTTPS on every site, memory safety, dynamic configuration, extensibility, and many more features valuable in a modern web server. Hope that helps :)
>I needed a quick and easy web server
I am trying to reason with what I know, but wouldn't something like "python -m http.server 9000" suffice? Or nginx? These are battle tested and python is there on most platforms.
Or is there more depth to this specific web server that others don't have?