gateway: CORS and `Cache-Control: only-if-cached` about specs HOT 1 OPEN

Thanks for raising this issue @MarcoPolo

The problem I mentioned was browsers blocking only-if-cached in cross-origin requests. There was some back and forth around this (whatwg/fetch#159, whatwg/fetch#295) and https://fetch.spec.whatwg.org states:

"only-if-cached"
Fetch uses any response in the HTTP cache matching the request, not paying attention to staleness. If there was no response, it returns a network error. (Can only be used when request’s mode is "same-origin". Any cached redirects will be followed assuming request’s redirect mode is "follow" and the redirects do not violate request’s mode.)

Thing to confirm to check if setting Access-Control-Allow-Headers lifts the "Can only be used when request’s mode is same-origin" limitation in all browsers (Chromium, Firefox, Safari) and allows example.com to do cross-origin fetch from ipfs.io.

If setting Access-Control-Allow-Headers is enough, I agree, we should document it in the spec. I think we need a dedicated CORS section in "Notes for implementers" anyway (some prior art in /routing/v1 spec)

If it is not enough, then we may need IPFS-specific solution, probably a dedicated HTTP header Ipfs-Cache-Control and URL query parameter for controlling the cache behavior beyong HTTP semantics ('get', 'has' 'get-only-if-has'). But would be nicer if we don't need this.

@MarcoPolo Would you have time to check current state of only-if-cached and open a PR to update specs to make it work?

We would then apply fix in boxo/gateway and add conformance tests to https://github.com/ipfs/gateway-conformance.

from specs.