AlinsRan commented on code in PR #13763:
URL: https://github.com/apache/apisix/pull/13763#discussion_r3755030271


##########
t/lib/chaitin_waf_server.lua:
##########
@@ -36,6 +36,33 @@ function _M.pass()
     ngx.exit(200)
 end
 
+-- Like pass(), but keeps answering until the client goes away. The client 
pools
+-- the connection and sends the response report over the same one, so a handler
+-- that answers once and exits would make that second report fail.
+function _M.pass_keepalive()
+    local sock = get_socket()
+
+    while true do
+        sock:send({ string.char(65), string.char(1), string.char(0),
+                    string.char(0), string.char(0) })
+        sock:send(".")
+        sock:send({ string.char(165), string.char(77), string.char(0),
+                    string.char(0), string.char(0) })
+        sock:send("{\"event_id\":\"1e902e84bf5a4ead8f7760a0fe2c7719\"," ..
+                  "\"request_hit_whitelist\":false}")
+
+        -- block until the next report arrives, so the connection stays usable;
+        -- reading one header byte is enough to tell a new report from a close
+        local data, err = sock:receive(1)

Review Comment:
   `sock:receive(1)` consumes one byte, not one message, so the loop emits a 
full t1k reply per byte received — instrumenting the handler showed 835 replies 
for a single request.
   
   More importantly the rationale doesn't hold: in that run the two reports 
went over two different connections (`*72` / `*77`), i.e. the client does not 
reuse the pooled connection for the response report. `pass()` is sufficient and 
this helper can be dropped.
   
   Consequence for TEST 2: `reported response` only proves the client received 
*a* well-formed t1k reply (likely a stale buffered copy), not that the mock 
received and parsed the response report. Asserting that would require the mock 
to read whole messages and check for the `RSP_HEAD` / `RSP_BODY` tags.



-- 
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