What?

Reorders the header spread in httpV1Middleware so that Content-Type: application/json acts as a default rather than an unconditional overwrite. Caller-provided Content-Type headers are now preserved.

Why?

The middleware currently places Content-Type: 'application/json' after ...options.headers in the spread, which means any custom Content-Type set by the caller is silently lost:

// Before (broken): caller's Content-Type is always overwritten
headers: {
    ...options.headers,
    'X-HTTP-Method-Override': method,
    'Content-Type': 'application/json',  // wins every time
},

This makes it impossible to send non-JSON content (e.g. raw markdown, plain text, XML) via apiFetch using PUT, PATCH, or DELETE methods. The server receives raw content labeled as application/json and returns 400 Invalid JSON body passed.

How?

One-line reorder — move Content-Type before the caller's header spread so it acts as a default:

// After (fixed): Content-Type is a default, caller can override
headers: {
    'Content-Type': 'application/json',  // default
    ...options.headers,                  // caller wins
    'X-HTTP-Method-Override': method,    // always forced
},

• Callers who don't set Content-Type still get application/json (backwards compatible)
• Callers who do set a custom Content-Type have their value respected
• X-HTTP-Method-Override remains after the spread and cannot be overridden by callers (correct security behavior)

How was this discovered?

While building a WordPress plugin (Data Machine) that saves markdown files (agent memory files — SOUL.md, MEMORY.md) via a custom REST endpoint. The admin page used apiFetch with method: 'PUT', headers: { 'Content-Type': 'text/plain' }, and body: rawMarkdownContent. Saves failed with 400 Invalid JSON body passed because the middleware silently overwrote the Content-Type.

Testing

Automated

• 11 new unit tests added to packages/api-fetch/src/middlewares/test/http-v1.ts
• All 60 tests across the entire @wordpress/api-fetch package pass (9 suites, 0 failures)
• Tests cover: Content-Type preservation, default behavior, all override methods (PUT/PATCH/DELETE), header preservation, non-override methods untouched, body integrity, case-insensitive method matching

Manual (production site)

• Patched api-fetch.min.js on a live WordPress 6.9 site (chubes.net)
• Confirmed Content-Type: text/plain survives through the middleware to the server (verified via Chrome DevTools Request Headers)
• Successfully saved raw markdown content via PUT request through apiFetch
• Confirmed X-HTTP-Method-Override: PUT is still correctly set and forced

Fixes #76284

AI Disclosure

Per the WordPress AI Guidelines, this contribution was made with meaningful AI assistance:

• Tool used: Claude Code (Claude claude-opus-4-6 via Anthropic's CLI, running through Kimaki Discord integration)
• How AI was used: The bug was discovered and diagnosed collaboratively — I (Chris Huber) encountered the 400 error while building the Data Machine plugin, and Claude Code helped trace the root cause through the httpV1Middleware source code, identify the spread order issue, propose the fix, write the comprehensive test suite, and draft the PR description. The fix itself (reordering one line) was straightforward once the root cause was identified.
• Human verification: I reviewed all code changes, confirmed the fix on my production WordPress site via browser DevTools (verifying the actual HTTP headers sent), and approved the PR submission. The root cause analysis, fix logic, and test coverage were all validated by me before submission.
• The full debugging session included: reading the Gutenberg source, tracing the middleware chain, patching the built JS on a live site, working around a Cloudflare cache issue (the version hash is hardcoded in script-loader-packages.min.php), and confirming the fix with real browser requests saving real markdown files.