This seems like good library design. As annoying as it is, it means the things you can use are well tested and supported.
What was your solution to this? Parse the things the library didn't?
What was your solution to this? Parse the things the library didn't?
In my view it's a very bad design for an http library, although it would have been a lot less frustrating if it had at least provided an escape hatch.
I typically design code around things like this with a sum type like:
data Header = KnownHeader1 | KnownHeader2 | UnknownHeader String String
Which I agree, is a poor design choice. A type modeling an HTTP request should model the RFC definition as closely as possible.
I couldn't disagree more. A type modeling an HTTP request should model HTTP requests. Not some theoretical description of an HTTP request.
They're created by something, but that something has more to do with a million blog posts and hallway conversations than it does with the formal RFC process. Certainly for most specifications of this kind, the working code came first and the specification was based largely on discovering what existing implementations did. If what the specification says is different from what HTTP clients send and HTTP servers understand, so much the worse for the specification.
But in this universe, no.
To be less snarky, the RFC defines what a well-formed HTTP request is. In the wild there are a lot of malformed HTTP requests that business cases may require handling.