Align Fetch-like APIs with MDN semantics

[medz]

Problem

Follow-up from the audit done while fixing #34 / #35. Several fetch-like APIs still deviate from MDN / WHATWG Fetch behavior or from browser behavior in ways that should be reviewed separately from the narrow Headers(Headers) fix.

This issue is now a tracking index. Use the split issues below for investigation and implementation discussion.

Split issues

• Align native Headers iteration with Fetch semantics #37
• Set default Content-Type from Request and Response body init #38
• Normalize Blob and File MIME type inputs #39
• Align Response.json default Content-Type with Fetch #40
• Define wrapper Response(Response, init) semantics #41
• Decide RequestInit method and modern Fetch surface parity #42

Original findings

• Headers.entries() / Headers.values() on the native implementation expose the raw header list. Browser Headers combines repeated non-set-cookie values while preserving set-cookie values separately, so native and JS behavior can diverge. Tracked in Align native Headers iteration with Fetch semantics #37.
• Request / Response constructors do not automatically set Content-Type from the body type when init headers omit it. Browser behavior sets values such as text/plain;charset=UTF-8 for string bodies and application/x-www-form-urlencoded;charset=UTF-8 for URLSearchParams bodies. Tracked in Set default Content-Type from Request and Response body init #38.
• Blob, File, and Blob.slice(..., contentType) preserve the supplied type string verbatim. Browser/File API behavior lowercases ASCII MIME types and uses an empty string when the supplied type contains invalid characters. Tracked in Normalize Blob and File MIME type inputs #39.
• Response.json() defaults to application/json; charset=utf-8; Fetch uses application/json unless callers explicitly provide a content type. Tracked in Align Response.json default Content-Type with Fetch #40.
• IO/JS wrapper Response(Response, init) currently aliases the wrapped response host and ignores init. Since this is not a standard Response() constructor shape, decide whether to remove it or define it as clone/copy semantics. Tracked in Define wrapper Response(Response, init) semantics #41.
• RequestInit.method is represented as HttpMethod, and newer Request/RequestInit fields such as signal, priority, and targetAddressSpace are not represented. This may be acceptable as a scoped API choice, but should be explicit if MDN surface parity is the goal. Tracked in Decide RequestInit method and modern Fetch surface parity #42.

References

• https://developer.mozilla.org/en-US/docs/Web/API/Headers/Headers
• https://developer.mozilla.org/en-US/docs/Web/API/Request/Request
• https://developer.mozilla.org/en-US/docs/Web/API/Blob/Blob
• https://developer.mozilla.org/en-US/docs/Web/API/Blob/slice
• https://developer.mozilla.org/en-US/docs/Web/API/File/File
• https://fetch.spec.whatwg.org/

Current validation context

At the time of this audit, the existing test suite passed:

• dart analyze
• dart test

[coderabbitai]

🔗 Related PRs

#13 - fix(fetch): urgently correct broken request implementation [merged]
#35 - fix(fetch): copy IO Headers constructor input [merged]
#44 - fix(fetch): set body-derived content type defaults [merged]
#45 - fix(fetch): normalize blob and file MIME types [closed]
#46 - fix(fetch): copy wrapped response inputs [closed]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!