The response existed. The kernel evidence arrived. nginx stopped the stream. The client received zero body bytes.
R1 demonstrated synthetic HTTP/2 containment, with a failed CPU budget. R2 established independent AppArmor prevention and isolated kernel-audit receipt. R3 asks whether genuine evidence can traverse that boundary in time for nginx to withhold an already-ready response.
The distinction matters: AppArmor prevents the defined native operation. nginx decides whether to deliver the response. Neither a denial nor a server-side abort proves what the client received; that requires a separate client-byte oracle.
Each case used a fresh experimental nginx worker, backend and authenticated session, with one HTTP/2 request in flight. The backend submitted HTTP 200 and the complete fixed 8,192-byte fixture body immediately.
The experimental gate held downstream delivery before header/body filter entry. Matching accepted evidence could abort the stream during that window; expiry without accepted evidence released the response as unverified. No challenge page or replacement body was evaluated.
The native operation ran independently after response submission. An nginx abort could not cancel the operation or create a false prevention result.
A separate HTTP/2 client recorded response headers, DATA bytes, END_STREAM and reset codes. Complete cases required an exact 8,192-byte body match. E1 required no response headers and zero DATA bytes, followed by RST_STREAM / INTERNAL_ERROR.
The repeated body pattern is a controlled fixture, not a malicious-content classifier. E2 and E3 legitimately deliver it.
E1 originated in a genuine AppArmor kernel audit denial of the actual protected write-open, returning EACCES. An isolated trusted observer validated the record before forwarding authenticated evidence to nginx.
Four predeclared primary cases, each executed once. Three actual native operations: two protected-canary attempts and one unrelated-target attempt. All four case expectations passed.
| Case | Evidence | Client body bytes | Client result |
|---|---|---|---|
| E1 / matching during hold | Genuine AppArmor denial accepted in time | 0 | No response headers or DATA; RST_STREAM / INTERNAL_ERROR |
| E2 / no denial | No native operation or denial | 8,192 | HTTP 200, exact body, END_STREAM; released unverified |
| E3 / unrelated denial | Genuine backend denial rejected as unrelated | 8,192 | HTTP 200, exact body, END_STREAM |
| E4 / late matching denial | Genuine matching denial accepted after delivery | 8,192 | HTTP 200, exact body, END_STREAM; no retroactive retraction |
In E1, nginx had parsed upstream HTTP 200 and preread 3,996 body bytes before entering the nominal 20 ms hold. The zero-byte result did not depend on an origin that had yet to produce its response.
Matching evidence was accepted approximately 16.27 ms before the nominal hold deadline. nginx aborted before downstream header/body filter entry. The independent client saw no response headers, no DATA and an INTERNAL_ERROR stream reset.
This is one observed margin, not a latency guarantee or a measured production tail distribution.
The client had received all 8,192 bytes before the protected native operation even began. Matching evidence was accepted approximately 31.72 ms after the nominal deadline. The completed stream was not reset.
Late evidence cannot retract delivered bytes. The hold can only contain output that has not yet crossed the delivery boundary.
Timing comparisons use same-boot monotonic actor timestamps and syscall brackets. Delayed parent logging and audit wall-clock identifiers are not treated as exact kernel-event creation times.
This was a harmless, isolated single-stream fixture campaign. It establishes neither general exploit prevention nor concurrent request attribution, production latency bounds or acceptable operating cost.
R1 passed scoped synthetic containment but failed its CPU gate: +22.10% versus stock nginx against a +10% target. R3 is not a matched cost benchmark and does not repair that result.
Concurrent HTTP/2 attribution, other transports, hostile-worker behavior and receiver failure/restart behavior require independent validation.
Two zero-request engineering attempts preceded the primary cases: an invalid nginx configuration and an isolated helper-import failure. The initial cleanup deadline failure and subsequent successful cleanup remain separately documented. No completed primary case was repeated or tuned into success.
Final independent review and cleanup passed: experimental security state and runtime fixtures were removed, original audit settings restored, and recorded existing service identities and configurations preserved. These checks are not a full user-data or system-recovery guarantee.
KISS remains the objective: minimal permanent components, narrow upstream patches, independent enforcement and explicit trust boundaries. A functional result earns a more precise question; it does not by itself earn a production component.
One genuine denial, two concurrent requests sharing one backend process. Could the unchanged evidence interface select the affected HTTP/2 stream?
| Case | HTTP/2 Stream A | HTTP/2 Stream B |
|---|---|---|
| C0 / no denial | 8,192 bytes, complete | 8,192 bytes, complete |
| C1 / A causes denial | 0 bytes, reset | 0 bytes, reset |
| C2 / B causes denial | 0 bytes, reset | 0 bytes, reset |
Both requests ran in separate threads of the same backend process. Both nginx response holds were active before the kernel operation, and genuine authenticated evidence arrived before both nominal 20 ms deadlines. The unchanged Gate B applied its service/invocation alert to both matching requests. The legitimate stream therefore suffered collateral containment.
AppArmor audit supplied the shared thread-group PID, not the actual syscall TID. Thread names were task-controlled, and no trustworthy HTTP-request-specific or stream-specific evidence binding existed. The independent client observed two separate RST_STREAM / INTERNAL_ERROR outcomes with no response headers or DATA; a connection-wide shutdown or connection-scoped security policy was not established.
Can nginx reliably associate a specific HTTP/2 upstream request with the PHP-CGI process actually executing it, using independently established kernel/socket identity rather than application-supplied claims?
The near-term target is the operator's actual PHP-CGI deployment. PHP-FPM process-management behavior is not presumed equivalent; other backend languages and runtimes are deferred. The exact launch mode, CGI versus persistent FastCGI operation, process lifecycle, worker exclusivity and socket ownership are not yet established. A future read-only source/configuration study must establish those facts before an experimental implementation is considered.