Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP Headers Cleanup: API and Gateway #132

Open
2 of 22 tasks
lidel opened this issue Nov 9, 2018 · 3 comments
Open
2 of 22 tasks

HTTP Headers Cleanup: API and Gateway #132

lidel opened this issue Nov 9, 2018 · 3 comments
Labels
developers epic help wanted status/deferred Conscious decision to pause or backlog

Comments

@lidel
Copy link
Member

lidel commented Nov 9, 2018

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

  • 2018-Q4: Interop is a mixed bag. Some headers are tested, some are not or different values across implementations. A simple test script exists but is incomplete.

TODO

Go over below headers of interest and ensure proper safeguards are in place.

Gateway

API

Related

@lidel lidel added developers help wanted status/deferred Conscious decision to pause or backlog labels Nov 9, 2018
@lanzafame
Copy link

/cc @hsanjuan

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
@lidel
Copy link
Member Author

lidel commented Nov 27, 2018

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-Output

go-ipfs v0.4.18 defaults

(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

js-ipfs v0.33.1 defaults

(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

@lidel
Copy link
Member Author

lidel commented Nov 27, 2018

-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 [HTTP OPTIONS] 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
developers epic help wanted status/deferred Conscious decision to pause or backlog
Projects
None yet
Development

No branches or pull requests

3 participants
@lidel @lanzafame and others