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

Removing support for X-Ipfs-Gateway-Prefix #7702

Closed
lidel opened this issue Sep 28, 2020 · 6 comments · Fixed by #8902
Closed

Removing support for X-Ipfs-Gateway-Prefix #7702

lidel opened this issue Sep 28, 2020 · 6 comments · Fixed by #8902
Labels
kind/maintenance Work required to avoid breaking changes or harm to project's status quo need/community-input Needs input from the wider community need/triage Needs initial labeling and prioritization P3 Low: Not priority right now topic/gateway Topic gateway

Comments

@lidel
Copy link
Member

lidel commented Sep 28, 2020

Is X-Ipfs-Gateway-Prefix useful to anyone?

Probably not(?)

I searched gh projects and when this header is mentioned it is set to empty string "just in case" (or a repo is a fork of go-ipfs).

Looks like an old, long time dead feature, and that is for a reason: it was introduced in 2016 (#1971) and AFAIK the only use for it was displaying blog under ipfs.io/blog, which we stopped doing in 2018 (ipfs-inactive/blog#182).

Why we stopped using it?

Since 2016 we realized nesting multiple gateway types under single Origin on the web is too complex and brittle.
IPFS community moved towards dedicated Origins, which are much easier to isolate and reason about (we moved ipfs.io/blog to subdomain at blog.ipfs.io) and the need for X-Ipfs-Gateway-Prefix went away.

Proposal: remove support for X-Ipfs-Gateway-Prefix

Existence of this header makes gateway code harder to maintain, and suggests risky deployment decisions. Right now the header is already ignored in various places, but nobody seems to care to fill a bug report ;-)

Instead of fixing it I'd like to remove it from docs/config.md and gateway code to decrease complexity, avoid origin-related bugs in the future, and make it more clear that one should mount only one DNSLink per Origin.

If someone is still depending on this header, please comment below describing your use case.
A better way most likely exists.

"But I AM using it!"

If you are using it, please comment below and describe your use case.
Most likely there is a better/safer way to serve your use case these days.

@lidel lidel added topic/gateway Topic gateway need/triage Needs initial labeling and prioritization need/community-input Needs input from the wider community kind/maintenance Work required to avoid breaking changes or harm to project's status quo labels Sep 28, 2020
@jbenet

This comment has been minimized.

@lidel

This comment has been minimized.

@Stebalien
Copy link
Member

Deprecation proposal:

  1. Print big warnings for the next release cycle with a request to open an issue. We should be able to see this in the config (I think?) and log/print on daemon start.
  2. Remove it in the release cycle after that and refuse to start if it's configured.

@lidel
Copy link
Member Author

lidel commented Mar 19, 2021

Deprecation plan sgtm. Opened PR in #7994

lidel added a commit that referenced this issue Mar 19, 2021
lidel added a commit that referenced this issue Mar 30, 2021
@aschmahmann aschmahmann mentioned this issue May 14, 2021
71 tasks
@lidel lidel added the P3 Low: Not priority right now label Feb 3, 2022
@BigLep
Copy link
Contributor

BigLep commented Mar 10, 2022

@lidel : is the next step "Remove it in the release cycle after that and refuse to start if it's configured"? Is this a good candidate for @schomatis ?

@BigLep BigLep added this to the Best Effort Track milestone Mar 10, 2022
@lidel
Copy link
Member Author

lidel commented Mar 15, 2022

I will most likely remove the gateway part during refactor in #8758
When that happens, the remaining work is to remove config.PathPrefixes and updating them to "removed" in config docs.

lidel added a commit that referenced this issue Mar 15, 2022
- Moved UnixFS response handling to gateway_handler_unixfs*.go files.
- Removed support for X-Ipfs-Gateway-Prefix (Closes #7702)
lidel added a commit that referenced this issue Mar 15, 2022
- Moved UnixFS response handling to gateway_handler_unixfs*.go files.
- Removed support for X-Ipfs-Gateway-Prefix (Closes #7702)
lidel added a commit that referenced this issue Mar 15, 2022
- removed dead code after X-Ipfs-Gateway-Prefix is gone
  (#7702)
- escaped special characters in content paths returned with http.Error
  making them both safer and easier to reason about (e.g. when invisible
  whitespace unicode is copied)
@lidel lidel closed this as completed in 4cabdfe Mar 17, 2022
@lidel lidel moved this to ✅ Done in IPFS Shipyard Team Mar 17, 2022
@BigLep BigLep moved this from 🎉 Done to ☑️ Done (Archive) in IPFS Shipyard Team Mar 23, 2022
@lidel lidel reopened this Apr 21, 2022
lidel added a commit that referenced this issue Apr 21, 2022
lidel added a commit that referenced this issue Jul 26, 2022
lidel added a commit that referenced this issue Jul 26, 2022
Repository owner moved this from ☑️ Done (Archive) to 🎉 Done in IPFS Shipyard Team Aug 30, 2022
lidel added a commit that referenced this issue Aug 30, 2022
hacdias pushed a commit to ipfs/boxo that referenced this issue Jan 27, 2023
hacdias pushed a commit to ipfs/boxo that referenced this issue Jan 27, 2023
* feat: serveRawBlock implements ?format=block
* feat: serveCar implements ?format=car
* feat(gw): ?format= or Accept HTTP header

- extracted file-like content type responses to separate .go files
- Accept HTTP header with support for application/vnd.ipld.* types

* fix: use .bin for raw block content-disposition

.raw may be handled by something, depending on OS, and .bin
seems to be universally "binary file" across all systems:
https://en.wikipedia.org/wiki/List_of_filename_extensions_(A%E2%80%93E)

* refactor: gateway_handler_unixfs.go

- Moved UnixFS response handling to gateway_handler_unixfs*.go files.
- Removed support for X-Ipfs-Gateway-Prefix (Closes #7702)

* refactor: prefix cleanup and readable paths

- removed dead code after X-Ipfs-Gateway-Prefix is gone
  (ipfs/kubo#7702)
- escaped special characters in content paths returned with http.Error
  making them both safer and easier to reason about (e.g. when invisible
  whitespace Unicode is used)

This commit was moved from ipfs/kubo@4cabdfe
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/maintenance Work required to avoid breaking changes or harm to project's status quo need/community-input Needs input from the wider community need/triage Needs initial labeling and prioritization P3 Low: Not priority right now topic/gateway Topic gateway
Projects
No open projects
Archived in project
Development

Successfully merging a pull request may close this issue.

4 participants