Re:Web Development in Go
by weberc2 on Monday April 10, 2017 @01:42PM
(#14080795)
What's lacking in the HTTP library? The stock router isn't great, but it's pluggable. Also, serving static files has never been a problem http.StripPrefix("/tmp", http.FileServer(http.Dir("/tmp"))) (or something like that, I forget the details). I guess I didn't find it very hard to get into web development in Go with the standard library; I'm not sure there's enough friction to justify diving into third party libraries. :/
[ Parent
| on HN ]
Re:Web Development in Go
by kevinburke on Monday April 10, 2017 @01:45PM
(#14080839)
> serving static files has never been a problem
I address this in the post; there's no problem with it, but it requires that you (or your end users) come up with a solution for deploying static assets to production, figuring out the relative paths between the working directory and the asset directory, and ensuring that the right version of the binary loads the right version of the assets. An example of the type of difficulty here is that you couldn't remember how to do it off the top of your head.
If you compile them into the binary, you (or your users) don't have these problems.
I thought compiling them into the binary was a very clever idea!
I've always assumed that compiling assets into the binary meant the http.FileServer can't use sendfile. I guess this means lower performance at scale, but I've never verified if this actually happened or its effect.
When you serve files over https (which you always should) you can't use sendfile anyway. The data will have to be encrypted, so you can't have the kernel send the data straight into the socket.
I hadn't considered this before but it seems to make sense. If I have nginx configured with ssl and sendfile (X-Accel-Redirect) and my app sends an X-Accel-Redirect response to nginx, you're saying that it's not actually using sendfile under the hood?
Sendfile is just a kernel feature for directly sending a file to a socket. If you are doing literally anything other than just sending the raw bytes of the file over the network, it can't be used.
Yeah I'm aware that it's a system call that only knows about file descriptors. It's just that it just now hit me that a consequence of that is that a web server configured to use ssl _and_ sendfile isn't really using sendfile, short of some hairy hack of writing/encrypting the response into a file (maybe in-memory with something like memfd_create) and using sendfile on that, which would defeat the purpose of avoiding user-space entirely.
Looking at Linux’s sendfile [1], it should be possible to use it like that in principle (but not with the standard http.FileServer, I guess).