Too much time in HTTP Server blockingHandle()

Description

Previous changes reduced effects of slowloris/darkloris (search tickets for more info) but still seeing a lot of time stuck in blockingHandle(). Should we reduce timeouts more? Why seeing this so often? Are we not correctly flushing / batching in HTTP client? Or are the headers exceeding 1730 bytes regularly and we're losing one? Headers are not gzipped in this direction until I2CP. This is really bad to clog up the acceptor this long. Maybe we need multiple acceptors for busy servers?

Subtickets

Change History (3)

We have a pool of up to 65 threads to run blockingHandle() per-dest so really not a problem. Still need to investigate why, but the speculation above that we need multiple is wrong, we are good. Reducing priority.

There were several problems remaining with intra-line timeouts and enforcement of total timeout, caused by use of DataHelper?.readline(). In IRCServer also, for non-webirc mode only, which nobody uses anymore. All fixed shortly before the 0.9.19 release. First line and total header timeouts should now be strictly enforced. #335 also contributed to the problem and was fixed.

The first-line timeout of 15s and total timeout of 30s should be sufficient for most uses but is not configurable. The 65 thread limit is configurable. If anybody runs into trouble we could add configs for the timeouts.