feat(http): size-exceeded error variant

[ricochet]

Opting for documenting two floors, one for individual fields and the other for aggregate.

Exceeding implementation defined limits will fail with header-error.size-exceeded.

Specific minimum sizes are intentionally left unspecified. Implementations operate in diverse environments with varying constraints, so limits are implementation-defined.

Making operations fallible with size-exceeded is sufficient to ensure correct error handling without prescribing specific thresholds.

Part of #889

[pchickey]

This looks like a good fix to the p3 spec. But, I don't think this fully resolves #889, because we also need to add docs to the p2 spec as well.

[ricochet]

This looks like a good fix to the p3 spec. But, I don't think this fully resolves #889, because we also need to add docs to the p2 spec as well.

Ah good call, we should at least add docs to p2. I believe adding to the error variant in p2 would be a breaking change. We could introduce a new type error and mirror existing methods/funcs to fail with the new error type. What do you think?

[lann]

Are these unrelated changes?

[ricochet]

Required to get a passing CI. Guessing someone merged without them updated.

…

On Thu, Feb 26, 2026, 4:52 PM Lann ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ On proposals/cli/wit-0.3.0-draft/deps.lock <#891 (comment)>: Are these unrelated changes? — Reply to this email directly, view it on GitHub <#891 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHN34Y7VBYBCHIYLON5JI34N5TJNAVCNFSM6AAAAACWA44XT6VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTQNRTG4ZTGNBWGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[yoshuawuyts]

If we want to be defensive about the 0.3.x target, we could also consider adding an additional other variant too. In Rust core::io::ErrorKind has an Other variant which is intended to be used for any variants not captured by the existing variants. This has been historically useful because up to Rust 1.40 (November 2019) Rust did not have support for the #[non_exhaustive] attribute, and so ErrorKind could not be extended with more variants.

I checked and we already have other(string) variants for method and scheme. error-code also has a defensive variant (internal-error(option<string>)). Do people have thoughts about applying that more broadly?

---

edit: went ahead and filed a standalone issue for this: #892

[ricochet]

I used other(option<string>) to match error-code's internal-error(option<string>)

I could argue for the description being required, but we should aim to keep these two consistent.

[lukewagner]

Looks good to me too w.r.t #892.