-
Notifications
You must be signed in to change notification settings - Fork 2k
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
HTTP/2 request processing optionally #2211
Comments
The problem is not only GRPC requests, All HTTP2 traffic may have long connection stream, you can see my analyze in #2172 (comment) |
HTTP2 is stream base protocol, read the whole body is theoretically impossible, and it does not make sense. |
The way nginx does it, potentially ignoring Content-Length seems a bit strange. However most request / responses do follow the non infinite upload property... I think a timeout would be a good idea (maximum time spent reading request data) for sure. |
I agree 😆 cc @zhuizhuhaomeng |
@oowl I think we need to revert the previous PR and disable in GRPC only. cc @splitice
Will a large HTTP request body in http2 connection block other HTTP requestes in the same connection? @oowl |
It will block the same amount as http/1.1.That should be acceptable and consistent in behaviour. |
No, Nginx process HTTP2 one And I have chat with @zhuizhuhaomeng on IM about #2174 , It can not be revert, Openresty can not support HTTP2 read body now, So maybe we need to consider this is a feature( it's also blocked in |
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 consider extending the functionalities of ngx.req.socket to enable handling the traffic interaction within a single stream in OpenResty's Lua module. This is because there are still several limitations when it comes to the read_body API, even with timeout support. In my opinion, we could tackle this issue with a two-step solution: Step 1: Revert the previous pull request and introduce support for a timeout option in Step 2: Need to check whether ngx.req.socket works properly in the HTTP/2 or HTTP/3, if not, then enhance the capabilities of ngx.req.socket to accommodate both HTTP/2 and HTTP/3. I am willing to take on these tasks to address this issue. |
BTW I've reverted this for two different client applications and continue to experience no real problems. We don't have the concern of spiked requests though. The problems really are limited to certain use cases, use cases that could do with a line in the documentation. |
I agree, So we need to know what is the openresty option. cc @zhuizhuhaomeng |
@splitice Would you please show the config of your usages? |
What do you want @zhuizhuhaomeng? |
We recently got affected by this change as well. IMO we should not add too much restrictions to the
|
@dndx I 100% agree with your points. I think the root of the actual problem is that client_body_timeout is between reads. Which the nginx folks think is OK (I agree) and the openresty folks do not. This is definately not the way it should be fixed. For immediate effect fork and revert the commit. Thats what I'll be doing for the forseeable future. |
This should not been an issue. Even with |
If there is no problem getting the HTTP request body, then this restriction should be lifted. |
Hi, #2174 disabled the ngx.read_body API in HTTP/2 due to #2172, and #2237 tried to reduce the limitations, so #2237 allows the request with @zhuizhuhaomeng So #2174 and #2237 should be reverted, and we need to enhance the doc about the #2172 scenario, and give suggestions like using HTTP/2 end stream flag and client_body_timeout. |
I agree with revert #2174, Sacrificing the majority of user usage for the sake of a handful of technically perfect solutions does not seem reasonable in some cases, apologies for this, I was thinking too much about the technical stuff before. |
But I want to emphasize that client_body_timeout does not look like a solution, it would make |
Hi, I have submitted PR for the revert commit above these #2286, pls help me review. |
PR #2174 removes support for http request processing.
I think this should be optionally still supported, it is after all perfectly servisable in a HTTP/2 request response flow. Perhaps a timeout can be added to error on grpc (rather than spiking the request)?
The text was updated successfully, but these errors were encountered: