[fix] Expand list of allowed mime types for binary bodies

[JeanJPNM]

Fixes #1438 by expanding the list of allowed mime types for binary bodies.
This allows an endpoint to return a response body with the most commonly used binary mime types.

Before submitting the PR, please make sure you do the following

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpx changeset and following the prompts

[changeset-bot]

🦋 Changeset detected

Latest commit: e4fac6d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
@sveltejs/adapter-cloudflare-workers	Patch
@sveltejs/adapter-netlify	Patch
@sveltejs/kit	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[rmunn]

I think you need to look at https://github.com/sveltejs/kit/pull/1382/files, which added those checks, and make sure you've thought about all the other changes that PR made and whether they will still work if you remove those checks. For example, #1382 changes packages/adapter-cloudflare-workers/files/entry.js to return a Uint8Array if (and only if) the content type includes "application/octet-stream", and otherwise it returns request.text(). What's going to happen in that function if the content-type is "image/jpeg" and the request body was an image? Is request.text() going to be the right return value, or not? There are many other places where the text "application/octet-stream" appears in #1382's changes. Some of them may not need to be changed if you remove those checks, but some of them might. They definitely all need to be considered.

[JeanJPNM]

I can't think of a better solution, what do you think?

/** @param {string} type */
function isBinaryContentType(type) {
	return (
		type.startsWith('image') ||
		type.startsWith('audio') ||
		type.startsWith('video') ||
		type.includes('application/octet-stream')
	);
}

This would work in most cases, but should this be updated when someone wants to use a different content type header or should they just use application/octet-stream?

[JeanJPNM]

Is there a way to share core logic with the adapters?
I was thinking of making a function to make updating the constraints for binary content easier

[JeanJPNM]

I would use type.startsWith('application/json') since the presence (or absence) of the encoding does not change the behavior of the code

[benmccann]

Is there a way to share core logic with the adapters?

Here are some examples where we do that:

kit/packages/adapter-node/src/server.js

Line 1 in 06e1c25

import { getRawBody } from '@sveltejs/kit/node'; // eslint-disable-line import/no-unresolved

kit/packages/adapter-node/src/shims.js

Line 2 in 06e1c25

export { fetch, Response, Request, Headers } from '@sveltejs/kit/install-fetch'; // eslint-disable-line import/no-unresolved

[benmccann]

I would move this line back down where it was originally. No reason to declare it higher up since it's not used yet

[benmccann]

lgtm once the tests are passing. can you add a changeset as well?

[drzax]

The logic is possibly still too blunt. There are at least a few content types I'd consider common for which I think this would return the wrong result:

• image/svg+xml
• application/zip
• application/pdf

An escape hatch for the developer here might be useful too given all the potential edge cases that the wonderful world of mime types involves.

[JeanJPNM]

I know that's why I made #1829

[benmccann]

I sent #1890 to help with this