server-compat: Caddy

[shinagawa-web]

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

Goal

Manually exercise tinytap against Caddy and record what we can and can't observe, feeding the shared table in docs/server-compat.md.

This is manual exploration, not automated tests.

Setup

A minimal Caddyfile serving a "Hello, world" (respond) and a file_server static directory.

Caddy is Go-based and serves static files through http.ServeContent, so the same sendfile(2) fast path as the Go net/http issue likely applies — expect the static file body to be invisible while inline respond text is visible. Confirm and contrast.

Tasks

• Serve a "Hello, world" endpoint + a file_server static endpoint
• Run tinytap + curl against three body sizes: small (<256 B), medium (~1 KiB), large (~50 KiB)
• 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)
• Add a Caddy row block to docs/server-compat.md
• Note any surprises (TCP_CORK, MSG_MORE, kernel buffering) for Lift the 256-byte BPF payload sample cap #36

Done when

• docs/server-compat.md has Caddy × 3 body sizes filled in
• The doc records whether Caddy's file_server uses sendfile vs the visible respond path