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.
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.
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
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
