[RFC] "http-types" breakage / additions / rework
Haskell Community [Unofficial]
June 19, 2026
I would love to see any movement in the http-types front. It doesn’t feel like the package has found the sweetspot between usability, correctness and probably a lot of other aspects.
If you’re changing the api, I see 2 general directions:
* Go even lower, no ci: use patterns and bytestrings. And add a few low level convenient helpers for e.g. list values and case manipulation. This is probably not worth the effort compared to the breakage it might cause downstream.
* Go for Haskell’s real strength. Types guiding the programmer towards the correct usage by default. This would need some optional leniency for parsing and potentially even generating non-conforming data for bad clients? And probably also allow for adding some raw data manually to the otherwise conforming headers.
I’d love to see option 2, where for common headers I wouldn’t need to write helpers that correctly assemble data (e.g. cache headers, where multiple options may go on one line comma separated)
But I guess like most people here, we’re just happy that this library gets some much needed love. And that you’ve sent out a reminder for version bounds upfront.
Discussion in the ATmosphere