Re:Rust is a hard way to make a web API
by tyingq on Friday January 15, 2021 @09:33PM
(#25799424)
I have seen, though, a fair amount of Go applications with http[s] servers that are (unintentionally, I think) missing Content-length in the response, correctly handling HEAD/RANGE/etc requests, ETAGS, Expires, and so on. It seems like people aren't fully aware of what the bundled libraries do and don't do...and how that might affect end-to-end performance and load.
[ Parent
| on HN ]
I've never seen that in 5+ years of Go.
1) You don't have to touch Content-length since it's computed. https://golang.org/pkg/net/http/#ResponseWriter
2) ETAGS, expire, ect ... are not managed by the std lib, as it should not.
On 1), Looked, and yes, you're right, and it seems to have been there from the beginning. I think I may have been thinking of node.js on the Content-length having to be a deliberate action.
Re:Rust is a hard way to make a web API
by sockgrant on Friday January 15, 2021 @10:53PM
(#25799874)
Good to know but this is pretty small deal, easily fixed, also there's probably quite a few Go backend frameworks and I doubt all of them have this issue
Re:Rust is a hard way to make a web API
by joshxyz on Saturday January 16, 2021 @12:37AM
(#25800341)
On nodejs that is left on the userland. It's up to the user to provide content-type; content-encoding; provide etags, cache-control and 304; handle cross origin requests.
Which looks like the right choice. ExpressJS has some helpers for it but it's a soup of unpredictability and shitty performance. You'd want something as simple as uwebsockets.js