jinhua luo

The issue source was located. When we contruct frames for HTTP/2 response and reuse the same skbs from the backend, we forget to adjust the skb size according to the...

> As discussed we should place the trailer header in the trailing HTTP headers frame after the body. The same functionality in streaming (#498) and current operation. Yes, maybe we...

> I think this is nothing wrong to always put trailer headers to a separate HEADERS frame after response body, so probably we don't need to address this even in...

> I think we still need this for #498, which is also in this milestone, so probably it can be done in two PRs, but it doesn't make sense to...

We should reserve the fact of fixed-length or chunked for the response from the backend, no matter whether the cache is enabled (if the cache is enabled, then this fact,...

## ~1. This is a false issue~ The tls error comes from the kernel: `crypto_aead_decrypt`, which returns `-EBADMSG` and only happens when the OOM reaper already takes effect. That is,...

> no, it's must not be patched, it's PoC please use it as is. Otherwise you will got OOM, definitely. Yes, it's looks strange but I hacked this way just...

 **step16: the last possible partial ssl record may lost** https://github.com/tempesta-tech/tempesta/blob/c2982989414c07e252dd28b6cffb551ba3f398c7/fw/sock.c#L838 **step17: sk->sk_receive_queue is not purged** https://github.com/tempesta-tech/tempesta/blob/c2982989414c07e252dd28b6cffb551ba3f398c7/fw/sock.c#L901 --- The root cause of the tls error is that `si_wq` (which has...

> I think that it is better to implement new counter in frang and check max count of control frames as we do for all other limits in frang. Maybe...

**For "slow read":** The slow-read attack affects the CPU, memory, and incoming connection pool. So #498 does not cover the issue. **A simple solution:** 1. define a frang limit: `client_read_timeout...