Jun Ouyang
Jun Ouyang
This is because HTTP2 requests cannot fit the proxy-cache plugin scenario. In the case of an HTTP2 stream, enabling the proxy-cache plugin (like GRPC) may block the entire HTTP2 request...
GRPC is stream base protocol, and I did not understand this scenario, But I have conducted a thorough investigation into Nginx and Openresty code, this implementation may not be handled...
Openresty has many Nginx patches to do some features https://github.com/openresty/openresty/tree/master/patches, it's not a good idea to use `lua-nginx-module` with nginx to replace openresty. @poohlaha
If anyone can help me to reproduce this problem, I would be very willing to dig it up and fix it.
Maybe it's related to https://github.com/fooinha/nginx-ssl-ja3/pull/58
The problem is not only GRPC requests, All HTTP2 traffic may have long connection stream, you can see my analyze in https://github.com/openresty/lua-nginx-module/issues/2172#issuecomment-1486378063
HTTP2 is stream base protocol, read the whole body is theoretically impossible, and it does not make sense.
> I think a timeout would be a good idea (maximum time spent reading request data) for sure. I agree 😆 cc @zhuizhuhaomeng
> Will a large HTTP request body in http2 connection block other HTTP requestes in the same connection? @oowl No, Nginx process HTTP2 one `ngx_http_request_t` per stream, so every stream...
> Hi, HTTP/3 also faces similar issues in OpenResty. I have been thinking about how to address this problem. For achieving full-duplex communication in both HTTP/2 and HTTP/3, we can...