Typed Headers

[nielsenko]

The current implementation of typed headers presents several challenges that need addressing:

• Flexibility & customization
  Developers should be able to define their own typed header classes, customize parsing behavior, and extend functionality as needed without modifying the core library. It should be possible to mix-and-match strict vs non-strict parsing modes on a per-header, per-handler basis.

• Opt-in approach
  Forcing typed headers on all users create unnecessary complexity for some use cases. A gradual adoption approach allows developers to migrate at their own pace, maintaining backward compatibility with existing code while providing a clear path forward.

• Efficiency & performance
  Header parsing and serialization should have minimal overhead compared to raw string operations. This means avoiding unnecessary object allocations, optimizing parsing algorithms, and ensuring that typed headers don't become a bottleneck in request processing.

  The current implementation pays for typed headers up front in terms of memory usage. Some effort has gone into supporting lazy parsing, but some operations still force eager parsing.

• Custom header support
  Beyond standard HTTP headers, applications often define custom headers for specific functionality. The typed header system should provide an extensible framework that allows developers to easily define and use their own custom header types with the same benefits as built-in headers.

• Inter-isolate sharing
  Since Dart applications often use multiple isolates for concurrency, header objects should be easily transferable between isolates without expensive serialization/deserialization cycles. This requires careful consideration of the internal representation of header data.