{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihfou23iikagnaqlpeeqzuqy4ugffieubqrazh5hw35iq5f4cansa",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3moly5kdptgj2"
  },
  "path": "/t/rfc-http-types-breakage-additions-rework/14286#post_8",
  "publishedAt": "2026-06-18T22:16:05.000Z",
  "site": "https://discourse.haskell.org",
  "tags": [
    "XKCD comic about standards"
  ],
  "textContent": "viktor:\n\n> Specifically with regard to refactoring `Headers`, it may be prudent to not make the representation too constrained. While an application that is strictly conformant with the HTTP specifications must abide by the rules, the same is not necessarily true when parsing response headers from a less meticulously implemented peer. Received headers may well include duplicates, or include characters outside the permitted range.\n\nThe new implementations (the types) themselves don’t enforce any HTTP rules, though I only have strict parsing functions at the moment for some. So thank you for reminding me that lenient parsing functions might be a helpful addition.\nThe main benefit, though, is that the new implementations should be as fast or faster than the current ones, and that the functions manipulating them will make it easier to not make mistakes.\n(the new `HeaderName` for example is a `ByteArray` which is 3x faster in making comparisons (i.e. `(==)`) than a `ByteString`, which also speeds up lookups)\n\n* * *\n\nsimonmic:\n\n> Also with helper functions being added, it’s no longer just http types, right ?\n\nThe library already has helper functions since 2012, so it’s already more than just types, though I do get your point.\nI’m hesitant to create a new library though, because it feels a lot like the XKCD comic about standards.\n\n* * *\n\nKleidukos:\n\n> Bump the major version, that’s the signal that there’ll be breakage, and you have fulfilled your part of the versioning contract with downstream users.\n\nTrue, but seeing as this is such a fundamental package for web dev packages, just bumping the major-major version out of nowhere feels a bit like if `base` would suddenly bump to `5.0` without warning.\nYou have probably convinced me of just making this a major-major version, but I’ll probably first go around some major packages and inform the maintainers of the incoming change, so they will at least have a heads up to add bounds and such if they haven’t already.\n\n* * *\n\nBurningWitness:\n\n> I wouldn’t be surprised if `http-types` is the only package using `case-insensitive`, everyone downstream is forced to include it just to work with header names.\n\nI’ve done a quick comparison of the reverse dependencies, and a rough estimate is that about half of all packages that depend on `case-insensitive` also depend on `http-types`. There might be more that only depend on `wai`, for example, and thus indirectly depend on `http-types`’s types.",
  "title": "[RFC] \"http-types\" breakage / additions / rework"
}