These 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.
Wait, file-server without arguments does dynamic content (templating)?!
These 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.
Wait, file-server without arguments does dynamic content (templating)?! I assume that's just poorly phrased?
While 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…
These kind of servers are useful for quickly serving a folder of files locally. Security isn't a primary concern for these kind of use cases.
That is the argument of the first MVP by a startup and then it is their onlien product.
I have this seen also in automotive. "This is no problem, because this is not connected to the Internet." Then a few years later you have a DefCon presentation "GM hack, you can control the whole car via the Internet".
These 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.
While 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…
These kind of servers are useful for quickly serving a folder of files locally. Security isn't a primary concern for these kind of use cases.
Where are you hosting your client-side code? Let me see if I can shut it down…
While 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…
> 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.
While 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…
Thanks for your comment. I surely hope no one will even consider using this server for anything public-facing :) It's solely for testing on localhost. The shutdown endpoint is used for robust testing; I suppose I can hide it a bit more, like using an environment variable or something.
Just check a header for a secret key you generate when you startup. Easy peasy. This keeps you able to call it for testing (granted you read from stdout or passed the key to tests as a variable). Then some scripto ransomware User from Omgodisztan doesn’t shutdown your server from the tent he’s camped in with Starlink.