{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiee7jny6cz6koinzxsti566v4afpgnpjbklexh6d6sdf2ueqxsed4",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mol57x3cutg2"
  },
  "path": "/t/rfc-http-types-breakage-additions-rework/14286#post_2",
  "publishedAt": "2026-06-18T15:21:49.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "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\nSo `(CI ByteString, ByteString)` has the advantage of being able to represent whatever some response might throw at you, which may not be a true of a more constrained representation.\n\nThe one thing that one might change now is to use unpinned `ShortByteString` instead of `ByteString` values, but it is not clear that the small improvement is justified by the cost it might impose on all the users.\n\nSo my advice would be to **provide** and promote functions that one could use to construct and/or validate headers and sets of headers, but perhaps not change the representation to preclude handling values might lie outside the strict bounds of the HTTP specification.",
  "title": "[RFC] \"http-types\" breakage / additions / rework"
}