Eden Fetch JSON.stringifies body even when content-type is set to something else.

[dtinth]

I am building an endpoint that receives input in the NDJSON format.

When I use Eden to send a request to that endpoint, it turns out that Eden stringifies the string as JSON before sending.

Upon further digging, I found that the stringification behavior depends on the Content-Type header. However, I cannot get it to work.

Referring to:

eden/src/fetch/index.ts

Lines 66 to 89 in 7b982cf

	const contentType = options.headers?.['Content-Type']
	if (!contentType || contentType === 'application/json')
	try {
	body = JSON.stringify(body)
	} catch (error) {}
	const fetch = config?.fetcher || globalThis.fetch
	const queryStr = query
	? `?${new URLSearchParams(query).toString()}`
	: ''
	const requestUrl = `${server}${endpoint}${queryStr}`
	const headers = body
	? {
	'content-type': 'application/json',
	...options.headers
	}
	: options.headers
	const init = {
	...options,
	method: options.method?.toUpperCase() || 'GET',
	headers,
	body: body as any
	}

• If I use the header { 'content-type': 'application/x-ndjson' } (content-type with lowercase c, lowercase t), it doesn't work because according to line 66, Eden will only read the Content-Type header (with uppercase C, uppercase T). This causes

• On the other hand, if I use the header { 'Content-Type': 'application/x-ndjson' } (Content-Type with uppercase C, uppercase T), it also doesn't work because according to line 80, when generating the request header, it uses the content-type header (with lowercase c, lowercase t), this led to a duplicate header ({ 'content-type': 'application/json', 'Content-Type': 'application/x-ndjson' }) which is then serialized as a comma separated header value (Content-Type: application/json, application/x-ndjson)

My recommendation is to use the web standard Header object when preparing the header for sending with the fetch API, so we don't run into footguns about header case-sensitivity issues.

(Current workaround: I switched to use openapi-fetch for typesafe client instead. It relies on code-generation through openapi-typescript and @elysiajs/swagger which introduces an extra build step but it suits my use case for now.)