HTTP/2 session idle timeout review
- Dominant language
- Java
- Stars
- 4.1k
- Forks
- 2k
- Avg merge
- 3d 56m
- Merged PRs (30d)
- 48
Description
**Jetty version(s)**
12.0.x/12.1.x
**HTTP version**
HTTP/2
**Description**
`HTTP2Session` idle timeout handling comes from changes done in #552.
However, it may happen that the idle timeout event fired by `AbstractEndPoint` arrives in `HTTP2Session` where it is compared with a local idle time, which may be 1 millisecond smaller (e.g. 29999 ms), and be skipped.
The point of #552 was that it is possible in HTTP/2 to have the connection read from the network a number of DATA frames, queued them up and then go idle.
The application may read slowly, so the idle timeout would fire from the EndPoint, even though the application is actually slowly consuming those DATA frames.
Contrast this with HTTP/1, where each read would go to the network and therefore reset the `EndPoint` idle timeout.
Ideally, an HTTP/2 read should mark the `HTTP2Stream` as not idle, which would mark `HTTP2Session` as not idle, which would mark the `EndPoint` as not idle: in this way the idle timeout is handled by the `EndPoint` only (not also by the `HTTP2Session` like it is now).
We cannot rely on `Connection` implementation to always point to an `AbstractEndPoint`: for example, when using the PROXY protocol, the relationship is the following:
```
proxyEP <--> Connection
| ^
v |
sockEP -----------+
```
It's `sockEP` that controls the idle timeout, but the `Connection` cannot reach it if not "unwrapping" `proxyEP`.
And `proxyEP` does not extend `AbstractEndPoint`.
Contributor guide
Assessment
This issue has not been assessed yet.