feat(http/unstable): add RFC 9457 Problem Details response helpers

[tomas-zijdemans]

Adds @std/http/unstable-problem-details, a module for working with RFC 9457 – Problem Details for HTTP APIs.

RFC 9457 defines a standard JSON (and XML) format for machine-readable error responses from HTTP APIs. It is widely adopted across REST ecosystems and replaces the earlier RFC 7807. Having first-class support in @std/http gives Deno users a consistent, spec-compliant way to produce and consume structured error payloads without pulling in third-party libraries.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.39%. Comparing base (d2fb2d6) to head (c335e22).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #7033   +/-   ##
=======================================
  Coverage   94.38%   94.39%           
=======================================
  Files         628      629    +1     
  Lines       50178    50255   +77     
  Branches     8840     8867   +27     
=======================================
+ Hits        47360    47437   +77     
  Misses       2251     2251           
  Partials      567      567           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[kt3k]

Mostly looks good to me. Thanks for the suggestion. Left one minor suggestion

[bartlomieju]

Good RFC 9457 implementation — clean generics, solid type validation per §3.1, and thorough tests. A few things:

1. Missing PR description. Should explain what RFC 9457 is and why it belongs in @std/http.
2. parseProblemDetails(response) consumes the body. Calling response.json() means the body can't be re-read. Worth documenting this explicitly, since callers may not expect it.
3. isProblemDetailsResponse() only handles JSON. RFC 9457 also defines application/problem+xml. Fine to skip for now, but worth noting as a known limitation in the JSDoc.
4. normalizeParsedProblemDetails uses for...in with Object.hasOwn guard. Object.keys() or Object.entries() would be more idiomatic and avoid the need for the hasOwn check.

[tomas-zijdemans]

Good RFC 9457 implementation — clean generics, solid type validation per §3.1, and thorough tests. A few things:

1. Missing PR description. Should explain what RFC 9457 is and why it belongs in @std/http.

I attempted a new PR title and added PR desciption

2. parseProblemDetails(response) consumes the body. Calling response.json() means the body can't be re-read. Worth documenting this explicitly, since callers may not expect it.

Added a comment explaining this in the latest commit.

3. isProblemDetailsResponse() only handles JSON. RFC 9457 also defines application/problem+xml. Fine to skip for now, but worth noting as a known limitation in the JSDoc.

Added a comment explaining this in the latest commit.

4. normalizeParsedProblemDetails uses for...in with Object.hasOwn guard. Object.keys() or Object.entries() would be more idiomatic and avoid the need for the hasOwn check.

That would work equally well. The for...in with switch reads as a single linear pass where each key is validated in place. Object.keys() would also work and skip inherited properties the same way, but wouldn't meaningfully improve readability or correctness imho. But yes, either is fine so let me know if this is a must-fix.

[bartlomieju]

Works as is, thanks!