server-compat: nginx (static + reverse proxy)

[shinagawa-web]

Part of #37 (v0.2.0 server-compatibility exercise).

Goal

Manually exercise tinytap against nginx (both static file serving and reverse proxy) and record what we can and can't observe, feeding the shared table in docs/server-compat.md. nginx is the primary motivation for the sendfile investigation in #36.

This is manual exploration, not automated tests.

Setup

Two configurations:

• static — location / serving files from a root dir (sendfile on; is the nginx default)
• reverse proxy — proxy_pass to one of the other test servers; here the response body comes from nginx's proxy buffer (write/sendto), not from a file

sendfile on; means static bodies leave via sendfile(2) and never touch write — tinytap sees the headers but not the body. Toggle sendfile off; to confirm the body becomes visible. Watch for TCP_CORK (nginx tcp_nopush on;) coalescing headers + body.

Tasks

• Serve a "Hello, world" endpoint + a small file-serving endpoint (static); add a reverse-proxy endpoint
• Run tinytap + curl against three body sizes: small (<256 B), medium (~1 KiB), large (~50 KiB), for both static and reverse-proxy modes
• Capture for each:
  • per-syscall write sizes (raw event log)
  • whether the body is visible in TUI / how it's truncated
  • whether sendfile(2) is used (absence of write/sendto events on body bytes); compare sendfile on; vs sendfile off;
• Add nginx row blocks (static + reverse proxy) to docs/server-compat.md
• Note any surprises (tcp_nopush/TCP_CORK, MSG_MORE, kernel buffering) for Lift the 256-byte BPF payload sample cap #36

Done when

• docs/server-compat.md has nginx static and reverse-proxy × 3 body sizes filled in
• The doc clearly names the static-sendfile case as "capture impossible today" and contrasts it with the visible reverse-proxy path