Pico silently truncates requests with 257-512 headers and misclassifies >512 as incomplete #66

Severity: Medium — 2026-10-30 security review

The C# side claims "requests with more headers are rejected (false)" (bindings/dotnet/Glyph11.Pico/PicoParser.cs:26-27, cap MaxHeaders = 256), but the shim allows 512 (bindings/dotnet/Glyph11.Pico/native/pico_shim.c:6) and clamps:

• 257–512 headers parse successfully with the tail silently dropped;
• >512 headers make picohttpparser return −1 (picohttpparser.c:311-313), which maps to false — indistinguishable from "incomplete", so callers wait for more data that will change nothing.

Dropped headers (e.g. an Authorization at position 300) create a security-decision differential in layered setups: one tier sees the header, the other doesn't.

Fix: align the shim's cap with the managed MaxHeaders and reject rather than truncate.