fix: JS caching via Access-Control-Expose-Headers

[lidel]

This fix safelists additional headers allowing JS running on websites to read them when IPFS resource is downloaded via Fetch API.

These headers allow for making smart caching decisions (#8720) when IPFS resources are downloaded via Service Worker or a similar middleware on the edge.

@guseggert If possible, we should include it in 0.13 (I forgot to safelist them in #8720), but if it is too late, then please reassign this to 0.14.

[lidel]

I also included Content-Length because it was not implicitly safelisted initially by the browsers (whatwg/fetch#622, whatwg/fetch#626) and still, the current browser behavior is not consistent.

Click to expand - Firefox 100 and Chromium 1001

Works on localhost

Start go-ipfs 0.12.2 and 0.13-rc1, then go to https://example.com/ and try to access the header from js, by typing in browser console:

$ fetch('http://127.0.0.1:8080/ipfs/bafybeib4zuumguq4cgkt7caddeukb4ysijnehvntekrtu5afmet5ujvlka/package.json').then(response => console.table(Object.fromEntries(response.headers))) 

cache-control	public, max-age=29030400, immutable
content-length	4674
content-type	application/json
last-modified	Thu, 01 Jan 1970 00:00:01 GMT

👉 when local gateway is used, fetch is able to access content-length

Fails on ipfs.io

At the same time, JS running on https://example.com is unable to read content-length if ipfs.io is used:

$ fetch('https://ipfs.io/ipfs/bafybeib4zuumguq4cgkt7caddeukb4ysijnehvntekrtu5afmet5ujvlka/package.json').then(response => console.table(Object.fromEntries(response.headers))) 

cache-control	public, max-age=29030400, immutable
content-type	application/json
last-modified	Thu, 01 Jan 1970 00:00:01 GMT

Manually including it on our own safelist solves the problem.

[guseggert]

Not too late for 0.13, will include it