-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
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
Milestone
Comments
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
4 tasks
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Deprecation proposal:
|
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
@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 ? |
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
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
Context: ipfs/kubo#7702 (comment) This commit was moved from ipfs/kubo@2f105f7
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
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 atblog.ipfs.io
) and the need forX-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.
The text was updated successfully, but these errors were encountered: