Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
When using GoatCounter directly internet-facing it's liable to keep connections around for far too long, exhausting the max. number of open file descriptors, especially with "idle" HTTP/2 connections which, unlike HTTP/1.1 Keep-Alive don't have an explicit timeout. This isn't much of a problem if you're using a proxy in front of it, as most will have some timeouts set by default (unlike Go, which has no timeouts at all by default). For the backend interface, keeping a long timeout makes sense; it reduces overhead on requests (TLS setup alone can be >200ms), but for the /count request we typically want a much shorter timeout. Unfortunately, configuring timeouts per-endpoint isn't really supported at this point, although some possible workarounds are mentioned in [1], it's all pretty ugly. We can add "Connection: close" to just close the connection, which is probably much better for almost all cases than keeping a connection open since most people only visit a single page, and keeping a connection open in the off-chance they click somewhere again probably isn't really worth it. And setting *any* timeout is better than setting *no* timeout at all! --- In the email conversation about this, the other person mentioned that some connections linger for hours, so there *may* be an additional problem either in the Go library or in GoatCounter, since this is a really long time for a connection to stay open. Then again, it could also be weird scripts or malicious users 🤔 [1]: golang/go#16100
- Loading branch information