Summary

chain::has_last() in src/security/util.h checks cl->buf->last (a u_char* data pointer) instead of cl->buf->last_buf (the boolean "last buffer" flag). This causes the AppSec WAF output body filter to never detect end-of-response for responses with empty bodies (Content-Length: 0).

Problem

When an upstream returns a response with Content-Length: 0 and Content-Type: application/json (e.g. HTTP 202 Accepted with empty body), nginx sends an NGX_HTTP_LAST special buffer via ngx_http_send_special(). This buffer has:

• last_buf = 1 (this IS the last buffer)
• last = NULL (no data — buffer allocated with ngx_calloc_buf which zeros all fields)
• pos = NULL

chain::has_last() checks buf->last which is NULL → returns false → the WAF never detects end-of-response → stays in COLLECTING_ON_RESP_DATA stage forever → response headers remain buffered → nginx's send_timeout fires (default 60s) → returns 408 Request Timeout to the client.

For responses WITH body data, buf->last is non-NULL (points to actual data end), so has_last() accidentally returns true and the WAF proceeds normally. This is why only empty-body responses are affected.

nginx ngx_buf_t fields:

Impact

• Any upstream response with Content-Length: 0 and a parseable Content-Type (application/json, text/plain) will hang for 60 seconds and return 408 when AppSec is enabled
• Responses with body content are not affected (they work by accident because buf->last is non-NULL)
• Observed in production with nginx-datadog v1.16.1 on OpenResty 1.27.1.2

Root Cause Trace

1. do_header_filter(): is_body_resp_parseable() returns true (Content-Type: application/json) → enters COLLECTING_ON_RESP_DATA stage, buffers response headers
2. do_output_body_filter(): receives NGX_HTTP_LAST special buffer → chain::has_last(in) checks buf->last (NULL) → returns false → start_waf = false → WAF keeps waiting
3. Response headers stay buffered, never forwarded to client
4. send_timeout (60s) fires → nginx returns 408

Fix

One-line change: check buf->last_buf (the correct flag) instead of buf->last (the data pointer).

// src/security/util.h
 inline std::size_t has_last(ngx_chain_t const *ch) {
   for (ngx_chain_t const *cl = ch; cl; cl = cl->next) {
-    if (cl->buf->last) {
+    if (cl->buf->last_buf) {
       return true;
     }
   }
   return false;
 }

Reproduction

1. Configure nginx with AppSec enabled (datadog_appsec_enabled on)
2. Set up a proxy_pass upstream that returns 202 Accepted with Content-Length: 0 and Content-Type: application/json
3. Send a POST request through nginx
4. Observe: nginx hangs for 60s (send_timeout default), then returns 408 with bytes_sent: 0

Note on PR #281

PR #281 (merged in v1.11.0) fixed is_body_resp_parseable() to no longer skip parsing when content_length_n == 0. That fix is correct but introduced a new path where the WAF enters COLLECTING_ON_RESP_DATA for empty-body responses. The chain::has_last() bug has always existed but was previously masked because the WAF would skip body processing entirely for empty responses.