{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibnusp246tqwqjglklz5moqjya73foyufobbpjunu2jp6jopzv36e",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3momsxx6vpgj2"
  },
  "path": "/t/rfc-http-types-breakage-additions-rework/14286#post_12",
  "publishedAt": "2026-06-19T06:30:18.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "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.\n\nIf you’re changing the api, I see 2 general directions:\n\n  * 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.\n  * 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.\n\n\n\nI’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)\n\nBut 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.",
  "title": "[RFC] \"http-types\" breakage / additions / rework"
}