External Publication
Visit Post

[RFC] "http-types" breakage / additions / rework

Haskell Community [Unofficial] June 19, 2026
Source
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

Loading comments...