m.request: Automatic Content-Type for non‑JSON payloads

Managing Content-Type in Mithril.js Requests

For non-JSON payloads, m.request should not automatically set a Content-Type header. Instead, it should remain transparent to allow the browser's native XMLHttpRequest or fetch implementation to handle the payload. This prevents the common failure where a manually set header overrides the browser's ability to generate necessary metadata.

Payload-Specific Behavior

• FormData: The Content-Type must not be set manually. When FormData is passed as the payload, the browser automatically sets the header to multipart/form-data and appends the required unique boundary string. If m.request or the developer manually sets this header, the boundary string is omitted, and the server will fail to parse the request.
• Blob and ArrayBuffer: These binary types typically result in no Content-Type being set by the library. Depending on the browser, this may default to text/plain or remain empty. For these types, the developer should manually specify the MIME type (e.g., application/octet-stream) in the request options.

Implementation Guidelines

To handle these cases consistently, use the following patterns:

For Multipart Form Data:

m.request({
  method: 'POST',
  url: '/upload',
  body: formData // Let the browser set the Content-Type and boundary
});

For Binary Data:

m.request({
  method: 'POST',
  url: '/binary',
  headers: { 'Content-Type': 'application/octet-stream' },
  body: arrayBuffer
});

Verification and Diagnostics

To verify that headers are being handled correctly, use the browser's Network tab in Developer Tools:

1. Initiate the request.
2. Inspect the Request Headers.
3. For FormData, confirm the header looks like multipart/form-data; boundary=----WebKitFormBoundary....

Missing Diagnostic Detail: Are you targeting a specific legacy browser version (e.g., IE11) where FormData support differs from modern standards? This would necessitate a polyfill or a different payload strategy.