-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Server idle/read/write timeout support #1628
Comments
For an idle timeout in HTTP2, having the |
Yeah, that's what we're doing right now (30 second timeouts for HTTP/1 and 10 minute timeouts for HTTP/2), but ideally we'd be able to handle this more precisely. Thinking about it a bit more, the minimum set of functionality that would need to be in hyper is just an idle timeout and a request header timeout. Read/write timeouts can be managed by the service implementation outside of hyper. |
That does seem reasonable. So far, punting on timeout support has had the benefit of not being tied to a specific timer (or runtime). The core of hyper still works if you disable the |
I think we can preserve those goals. Initially, timeouts could require the runtime feature, and we could add an abstraction over timers to support other runtimes. |
I'd like to start moving on this. I think the simplest first step would be to handle server-side idle timeouts. As an initial approach, I'm thinking of tying support to the runtime feature - the setters like If there's interest we could make a trait abstraction for timers to support non-tokio runtimes, but that doesn't seem necessary initially. On the HTTP/2 side, we can identify if we're idle with some reference counting scheme with the Seem reasonable? |
EDIT: Nevermind, Go's behavior is to ignore pings for the purpose of idling, which makes sense to me! |
With the idle time configurable we can prevent a pile up of open connections which never see any activity. See also on the hyper issue tracker: ``` hyperium/hyper#3743 hyperium/hyper#1628 hyperium/hyper#2355 hyperium/hyper#2827 ```
On the server side, it's important to be able to clear out connections that have been idle for too long or are somehow broken. For HTTP/1, this can be done pretty simply by setting stream-level read and write timeouts. However, things aren't so simple for HTTP/2 since it's multiplexed. In particular, the server is always attempting to read from an HTTP/2 socket, so if a single request is active that takes more than the read timeout to process, the connection gets killed.
To handle this properly, I think we'll need hyper-level timeout configuration. In particular, I care about being able to shut down connections that have been idle for some period of time, and detect when reading from a client or writing to it is taking too long.
There are also some potential higher level timeouts to defend against e.g. slow loris attacks by placing a cap on the time a client is allowed to send the complete set of headers.
The text was updated successfully, but these errors were encountered: