ETag generation throws on binary responses since 1.0.0-next.82

[intrikate]

Describe the bug
Since 1.0.0-next.82, attempting to set a Content-Type header for certain binary responses in endpoint handlers will throw an exception: str.charCodeAt is not a function. Responding with no type or with explicit application/json won’t throw. Downgrading to next.81 fixes the issue. Upgrading to next.83 does not.

Update: This appears to be a regression introduced with the new ETag generation in #1117.

To Reproduce
Make an endpoint that responds with e.g. a JPEG with the Content-Type (or content-type) header set to image/jpeg.

See repo: https://github.com/intrikate/sveltekit-jpeg-endpoint-issue

Expected behavior
Content-Type set, the body sent, no exceptions thrown. Essentially what 1.0.0-next.81 does.

Stacktraces

Stack trace

str.charCodeAt is not a function
TypeError: str.charCodeAt is not a function
    at hash (file:///Users/leek/Code/Playground/sveltekit-jpeg-issue/node_modules/@sveltejs/kit/dist/ssr.js:1509:37)
    at render (file:///Users/leek/Code/Playground/sveltekit-jpeg-issue/node_modules/@sveltejs/kit/dist/ssr.js:1473:26)
    at async ssr (file:///Users/leek/Code/Playground/sveltekit-jpeg-issue/node_modules/@sveltejs/kit/dist/ssr.js:1454:10)
    at async Immediate.<anonymous> (file:///Users/leek/Code/Playground/sveltekit-jpeg-issue/node_modules/@sveltejs/kit/dist/chunks/index.js:3297:23)

Information about your SvelteKit Installation:

Diagnostics

System:
    OS: macOS 11.2.3
    CPU: (4) x64 Intel(R) Core(TM) i5-4288U CPU @ 2.60GHz
    Memory: 46.50 MB / 8.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 14.16.0 - /usr/local/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 6.14.11 - /usr/local/bin/npm
  Browsers:
    Chrome: 89.0.4389.128
    Firefox Developer Edition: 88.0
    Safari: 14.0.3
  npmPackages:
    @sveltejs/kit: next => 1.0.0-next.83 
    svelte: ^3.29.0 => 3.37.0 
    vite: ^2.1.0 => 2.2.1

Severity
Pretty high, especially if this is indeed a regression.

Because nobody else seems to be affected, and the entire hashing business may currently be circumvented with cache-control, I’m inclined to downgrade severity to low.

[intrikate]

More context:

kit/packages/kit/src/runtime/server/index.js

Lines 82 to 87 in e6f8098

	export function hash(str) {
	let hash = 5381,
	i = str.length;
	while (i) hash = (hash * 33) ^ str.charCodeAt(--i);
	return (hash >>> 0).toString(36);
	}

[drzax]

Did #1382 actually solve this? Unless I've missed something the changes actually prevent serving binary images in the way the example repo does.

[intrikate]

You’re right, it effectively kills binary endpoints, with one small exception. Is this really necessary?