{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifbn2e5k2o6t5uf2m2zy2gjn2v436eisyu2fqkwosdubdfhyfagu4",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3monnunyknr32"
  },
  "path": "/t/rfc-http-types-breakage-additions-rework/14286#post_18",
  "publishedAt": "2026-06-19T14:26:48.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "I totally understand the dissatisfaction with the current API, but breaking changes here seem like a major pain for little benefit. Earlier and stricter validation always causes problems in existing software (we just dealt with such a situation upgrading aeson, despite my having Hyrum’s Law top of mind and really trying to anticipate what could go wrong). And as others have pointed out e.g. the loose (or an even looser) definition of Headers is likely necessary, if only to return a useful error message to naughty clients. It could also be informative to know how e.g. chrome or nginx parse headers: how lax are they, where does validation occur.\n\nInstead I would go with your approach of adding validation functions or a Safe module that enforces tighter guarantees (e.g. TH for header name literals, a parsing function from loose Headers to `Safe.Headers`). Let libraries transition to those if they have value. But even here I’m really struggling to imagine any concrete benefit we could get that would be worth _any_ breakage, especially subtle breakage like learning Important Customer X uses a homegrown middleware that injects a header with a slash into every request and they simply couldn’t possibly change it because it would break their whole business.",
  "title": "[RFC] \"http-types\" breakage / additions / rework"
}