bzp2010 commented on PR #11350:
URL: https://github.com/apache/apisix/pull/11350#issuecomment-2171124820

   Hi, @zhoujiexiong. Thank you for your contribution.
   
   First the clarification part, `read_body` shouldn't be used at the same time 
as `ngx.req.socket`. The socket call puts the client connection into streaming 
read mode, which is a different mode than blocking reads.
   The documentation 
([https://github.com/openresty/lua-nginx-module?tab=readme-ov-file#ngxreqsocket](https://github.com/openresty/lua-nginx-module?tab=readme-ov-file#ngxreqsocket))
 explicitly mentions that `ngx.req.read_body` and `ngx.req.socket` should not 
be used at the same time, and `ngx.req.read_body` is used in 
`core.request.read_body`.
   
   This would be a systematic problem, and read_body and sockets are hard to 
avoid being used together, so perhaps we could consider modifying the 
core.request.read_body behavior so that it can read the request body as a 
stream.
   
   ------
   
   But I have some questions about forward-auth. I am the original author of 
the plugin.
   
   I don't think it's normal to send huge request bodies to an authentication 
service, or even to send any request bodies at all. This may defeat the purpose 
of the plugin as an extremely lightweight authentication middle layer in the 
first place. In contrast, the original design option of sending only request 
headers is probably better. (Yes, at first it didn't send request bodies at 
all, some other contributor added that feature.)
   
   Additionally, attempting to read huge request bodies into LuaVM side memory 
may break APISIX's excellent performance. It may be more efficient to let NGINX 
handle the sending of request bodies directly. If you do need to read the body 
into memory, it is best to control the body size.
   
   Can you comment on the necessity of this feature existing in forwath-auth 
itself? 🤔


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to