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.

Sign up for GitHub

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

Jump to bottom

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
Milestone
Best Effort Track

Comments

@lidel
Copy link
Member

lidel commented Sep 28, 2020 •
edited
Loading

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
@lidel lidel mentioned this issue Sep 28, 2020
Merged
4 tasks
@jbenet

This comment has been minimized.

Sign in to view
@lidel

This comment has been minimized.

Sign in to view
@dennis-tra dennis-tra mentioned this issue Dec 5, 2020
Merged
@lidel lidel mentioned this issue Mar 19, 2021
Merged
@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 •
edited
Loading

Deprecation plan sgtm. Opened PR in #7994

lidel added a commit that referenced this issue Mar 19, 2021
@lidel
chore: deprecate Gateway.PathPrefixes
341d2b5 
Context:
#7702 (comment)
@lidel lidel mentioned this issue Mar 20, 2021
Merged
lidel added a commit that referenced this issue Mar 30, 2021
@lidel
chore: deprecate Gateway.PathPrefixes
2f105f7 
Context:
#7702 (comment)
@aschmahmann aschmahmann mentioned this issue May 14, 2021
Closed
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 •
edited
Loading

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
@lidel
refactor: gateway_handler_unixfs.go
76519e5 
- 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
@lidel
refactor: gateway_handler_unixfs.go
d849115 
- 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
@lidel
refactor: prefix cleanup and readable paths
eb95d2b 
- 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 reopened this Apr 21, 2022
lidel added a commit that referenced this issue Apr 21, 2022
@lidel
chore: remove Gateway.PathPrefixes
d848c91 
Closes #7702
@lidel lidel mentioned this issue Apr 21, 2022
Merged
lidel added a commit that referenced this issue Jul 26, 2022
@lidel
chore: remove Gateway.PathPrefixes
68c5e26 
Closes #7702
lidel added a commit that referenced this issue Jul 26, 2022
@lidel
chore: remove Gateway.PathPrefixes
7932f66 
Closes #7702
lidel added a commit that referenced this issue Aug 30, 2022
@lidel
chore: remove Gateway.PathPrefixes
c9693ed 
Closes #7702
hacdias pushed a commit to ipfs/boxo that referenced this issue Jan 27, 2023
@lidel
chore: deprecate Gateway.PathPrefixes
8736ffc 
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
@lidel
feat(gateway): Block and CAR response formats (#8758)
3a09cab 
* 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
@lidel lidel mentioned this issue Feb 1, 2023
Closed
@lidel lidel mentioned this issue Jun 19, 2023
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
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
IPFS Shipyard Team
Archived in project
Milestone
Best Effort Track
Development

Successfully merging a pull request may close this issue.

chore: remove Gateway.PathPrefixes ipfs/kubo
4 participants
@BigLep @jbenet @lidel @Stebalien