HTTP Headers Cleanup: API and Gateway #132
Labels
Comments
|
/cc @hsanjuan |
This was referenced Nov 17, 2018
fsdiogo
pushed a commit
to ipfs-shipyard/ipfs-share-files
that referenced
this issue
Nov 19, 2018
Share App does not need this header. See also: - Potential problem with `Access-Control-Allow-Credentials`: ipfs/kubo#5745 - HTTP Headers Cleanup: ipfs/in-web-browsers#132
|
For the record, in Q4 2018 headers look like this 🙃 Public Gateway at ipfs.io$ 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-Outputgo-ipfs v0.4.18 defaults(equal to $ 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-Outputjs-ipfs v0.33.1 defaults(no $ 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 |
|
52 tasks
This was referenced Jul 8, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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-MatchheaderCache-Control:/ipfs/namespaceCache-Controlfor/ipns/– https://github.com/ipfs/go-ipfs/issues/1818 / No cache-control on Host: based requests kubo#5968 / disable-last-modified-behaviour-ipns-routes kubo#8074Stale-While-Revalidatein browsers https://www.mnot.net/blog/2014/06/01/chrome_and_stale-while-revalidateSuborigin: use root CID in base32 and literal prefix to conformto the current suborigin spec (Suborigins #66)
Last-Modifiedtopic/CORSin general: https://github.com/ipfs/go-ipfs/labels/topic%2FCORSX-Content-Type-Options: nosniffwhich causes CSS files to be returned astext/plain(relative links in files not added ipfs-shipyard/ipfs-deploy#86 (comment))API
Etag&Cache-Control: without this, all content addressed "gets" skip browser cache which results in degraded performance and wasted bandwidth (details: Add etag and other caching headers to all content addressed gets in api kubo#3543)X-Chunked-Output: various API endpoints break without it (eg. Unexpected X-Chunked-Output in /api/v0/version response kubo#5711)Access-Control-Expose-Header: without this, JS is unable to seeX-Chunked-Outputin Chrome ([CORS] Old library makes exploitable CORS configuration (need to update dependency) kubo#5745)User-Agentin default list ofAccess-Control-Allow-Headersto follow whatwg/fetch spec (Adduser-agentto default list ofAccess-Control-Allow-Headerskubo#5138)Access-Control-Allow-Credentialsshould be removed from docs as it is not used and may cause security issues in some setups.Related
403 - Forbiddenipfs-shipyard/ipfs-share-files#17 (comment): Gateway requests responds with 403 - Forbidden-Allow-Headersvs-Expose-HeadersThe text was updated successfully, but these errors were encountered: