Open lidel opened 5 years ago
/cc @hsanjuan
For the record, in Q4 2018 headers look like this :upside_down_face:
$ curl -s -I -X GET https://ipfs.io/ipfs/QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR | grep -i Access-Control
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: X-Requested-With, Range, Content-Range, X-Chunked-Output, X-Stream-Output
Access-Control-Expose-Headers: Content-Range, X-Chunked-Output, X-Stream-Output
(equal to ipfs config --json API.HTTPHeaders '{}'
)
$ curl -s -I -X GET http://127.0.0.1:8080/ipfs/QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR | grep -i Access-Control
Access-Control-Allow-Headers: Content-Range, X-Chunked-Output, X-Stream-Output
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Methods: GET
Access-Control-Allow-Methods: POST
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Content-Range, X-Chunked-Output, X-Stream-Output
(no API.HTTPHeaders
in config)
$ curl -s -I -X GET http://127.0.0.1:9090/ipfs/QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR | grep -i Access-Control
access-control-allow-headers: X-Stream-Output, X-Chunked-Output, X-Content-Length
access-control-expose-headers: X-Stream-Output, X-Chunked-Output, X-Content-Length
-Allow-Headers
vs -Expose-Headers
There is an important nuance: Access-Control-Allow-Headers
tells browsers which headers can be used in XHR CORS request and Access-Control-Expose-Headers
whitelists which response headers will be available to be read by JS:
The
Access-Control-Allow-Headers
response header is used in response to a preflight [HTTPOPTIONS
] request which includes the Access-Control-Request-Headers to indicate which HTTP headers can be used during the actual request.The
Access-Control-Expose-Headers
response header indicates which headers can be exposed as part of the response by listing their names.
Summary
We should have:
Interop tests that ensure HTTP responses have the same headers and values, no matter which implementation is the backend
Diagnostic tool/script that can be run against any HTTP API or Gateway port and provide quick health status
Status
TODO
Go over below headers of interest and ensure proper safeguards are in place.
Gateway
X-Ipfs-Path
: IPFS Path of returned resourceEtag
: resolved CID/multihash of returned payloadIf-None-Match
headerCache-Control
:/ipfs/
namespaceCache-Control
for/ipns/
– https://github.com/ipfs/go-ipfs/issues/1818 / https://github.com/ipfs/go-ipfs/issues/5968 / https://github.com/ipfs/go-ipfs/pull/8074Stale-While-Revalidate
in browsers https://www.mnot.net/blog/2014/06/01/chrome_and_stale-while-revalidateSuborigin
: use root CID in base32 and literal prefix to conform to the current suborigin spec (https://github.com/ipfs/in-web-browsers/issues/66)Last-Modified
topic/CORS
in general: https://github.com/ipfs/go-ipfs/labels/topic%2FCORSX-Content-Type-Options: nosniff
which causes CSS files to be returned astext/plain
(https://github.com/ipfs-shipyard/ipfs-deploy/issues/86#issue-484313696)API
Etag
&Cache-Control
: without this, all content addressed "gets" skip browser cache which results in degraded performance and wasted bandwidth (details: https://github.com/ipfs/go-ipfs/issues/3543)X-Chunked-Output
: various API endpoints break without it (eg. https://github.com/ipfs/go-ipfs/issues/5711)Access-Control-Expose-Header
: without this, JS is unable to seeX-Chunked-Output
in Chrome (https://github.com/ipfs/go-ipfs/issues/5745)User-Agent
in default list ofAccess-Control-Allow-Headers
to follow whatwg/fetch spec (https://github.com/ipfs/go-ipfs/issues/5138)Access-Control-Allow-Credentials
should be removed from docs as it is not used and may cause security issues in some setups.Related
-Allow-Headers
vs-Expose-Headers