Structured Fields Need One Parser at Every Trust Boundary
HTTP fields are often parsed by several components before an application sees a decision. A proxy may inspect a cache directive, a gateway may check a signature and an origin may parse the same bytes for authorization. If those components disagree about whitespace, duplicate members, parameter order or type conversion, the system can enforce one meaning while acting on another.
RFC 9651 defines Structured Field Values for HTTP. It provides typed Items, Lists and Dictionaries with a precise parsing and serialization model. A field definition can specify an Item, List or Dictionary and can constrain parameters. The benefit comes from shared behavior, not from placing quotes around a value and calling it structured.
The trust-boundary problem is easiest to see in a signed request. A signer canonicalizes selected fields and sends a signature. A verifier must reconstruct exactly the same component values using the same field type and canonical form. If the verifier treats a dictionary-like string as opaque text while the signer uses the structured serializer, a duplicate key or changed whitespace may produce a valid signature over a different policy interpretation.
RFC 9421 uses Structured Fields where available to make HTTP Message Signature component values deterministic. Even outside signing, the same principle applies to cache controls, authentication metadata, tracing policy and custom gateway fields. One parser should produce a validated data structure, and every downstream policy should consume that structure.
Practical controls begin with field definitions. Reject values that the selected field type does not allow. Decide whether duplicate dictionary keys are an error, last-value-wins or a policy violation. Limit total length, list members and depths so a parsing error does not turn into an unbounded allocation. Record the normalized value that the security decision used.
Do not compare a signature or policy against a hand-built concatenation of raw header text. Use the library's canonical serializer and confirm that all components are present, unambiguous and allowed for the request context. Header names are case-insensitive, but Structured Field member keys and some tokens have their own rules. String case is data, not a normalization convenience.
Proxy chains need a named owner for each field. If a gateway strips a client value and writes its own, the origin should not accept the client's version as equivalent. If a component is not understood, forwarding it unchanged can be safer than guessing, but the security policy must state whether unknown structured parameters are ignored or rejected.
Tests should include quoted strings with escaped characters, duplicate dictionary keys, invalid bare tokens, byte sequences, parameters in different orders and values near configured limits. Send the same bytes through each proxy and compare the parsed decision object. A test that only checks the final HTTP status can miss a parser disagreement when both paths happen to deny a different reason.
Structured Fields reduce ambiguity when the whole chain adopts the type model. The remaining risk is governance. A field without a defined type, a second unofficial parser or a component that rewrites values without recording the change can defeat the benefit. Put the parser and normalization rules under version control, expose their output to tests and review changes as security-sensitive code.
Top comments (0)