-
-
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
feat(gateway): _redirects file support #8890
Conversation
@lidel When you have time, gentle bump on getting your feedback to the comments above. I really appreciate the time and feedback you've given me already. 🙏 At this point I have what feels like the right MVP functionality working ( Also, related to your go-redirects comments... it feels to me like we should not use a library dedicated to parsing Netlify's _redirect file, and instead have our own library whose specific goal is to support the functionality in the redirect IPFS spec (to be written). For now I'm thinking this is essentially a fork of go-redirects that only supports If you disagree and want me to stick with a repo that specifically supports Netlify's syntax, I still had to fork the repo since it is no longer maintained, and it seems to me there wouldn't be any reason to add all the existing Netlify parsing logic right away, since the MVP won't support all of those features anyway. For convenience for anyone wanting to evaluate the changes...
|
FYI, I'll be out for a few weeks but will be checking email in case there is any PR feedback. I'm sure there will be things to address but I'm going to mark this as ready for review now. |
After some discussion with @b5 and @dignifiedquire, I'm leaning toward pulling out forced redirect support to avoid a performance hit for anything other than non-existent paths (i.e. read |
Review status... @lidel is wrapping up specs for existing gateway functionality and then hopes to get to this, possibly next week or the week after. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First, thank you for your patience @justincjohnson 🙌
I will be OOO Thu-Fri due to Holiday, and will do proper review of go code in this PR when I am back, but to get things going, quick feedback:
Moving go-ipfs-redirects to ipfs org
Good call on making a dedicated lib.
If you add me as Admin to https://github.com/justincjohnson/go-ipfs-redirects i'll move it to ipfs org + ensure you still have your permissions.
Creating RFC with specs
We want this to be a part of web gateway specs, and not just go-ipfs feature.
Good news is that we now have all the pieces in place to do the proper spec work:
- HTTP Gateway specs that describe state in go-ipfs 0.13 are in Add HTTP Gateway Specs specs#283 (still gathering feedback, but will be merged soon)
- Light RFC process for IPFS specs is proposed in Lightweight RFC Process specs#286 and IPIP 0001: Lightweight "RFC" Process for IPFS Specifications specs#289
Do you mind opening a PR against HTTP Gateway specs from ipfs/specs#283 that adds:
http-gateways/REDIRECTS_FILE.md
describing this feature- Include a copy of
RFC/0000-template.md
from IPIP 0001: Lightweight "RFC" Process for IPFS Specifications specs#289 describing motivation for adding_redirects
support.- we want this to be a lightweight process, so a single paragraph is enough to get the discussion started :)
When we have ipfs/specs PR with RFC,
I'll ping folks from other implementations to take a look and provide feedback, to ensure they are onboard too 👍
Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your angelic patience @justincjohnson ❤️
I did the first pass review of this along with IPIP (specifications) at ipfs/specs#290 – some questions / asks apply to both – details inline.
General ask for this PR is to rebase on top of latest master
to include new tests added in past few weeks.
// Returns the root CID Path for the given path | ||
func getRootPath(path string) (ipath.Path, error) { | ||
if isIpfsPath(path) { | ||
parts := strings.Split(path, "/") | ||
return ipath.New(gopath.Join(ipfsPathPrefix, parts[2])), nil | ||
} | ||
|
||
if isIpnsPath(path) { | ||
parts := strings.Split(path, "/") | ||
return ipath.New(gopath.Join(ipnsPathPrefix, parts[2])), nil | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: if you switch path
from string
to contentPath ipath.Path
, then you will be able to read namespace via contentPath.Namespace()
and simplify this
@lidel I believe I've addressed all feedback now. From my perspective the only question that is outstanding is ipfs/specs#290 (comment). I did add code to handle these extra http status codes, but it still feels to me like it may not make sense. My hope is that we are finally close to having this pushed across the finish line. 🤞 Thanks again for your assistance. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looks good, I've added some tests and moved library to the main org at https://github.com/ipfs/go-ipfs-redirects-file.
@justincjohnson will you have time to rebase this PR on top of master
again, so it builds with go1.19? When you do that, please address small asks below + ipfs/go-ipfs-redirects-file#11
Would like to ship this in Kubo 0.16 (or 0.17, depending on external factors, such as spec work and today's Implementers review), building with 1.19 is the main blocker.
// The path can't be resolved. | ||
// If we have origin isolation, attempt to handle any redirect rules. | ||
if hasOriginIsolation(r) { | ||
redirectsFile := i.getRedirectsFile(r, contentPath, logger) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: please move logic related to handling redirectsFile
to serveRedirectsIfPresent
similar to serveLegacy404IfPresent
Will make it easier to reason about, and easier to refactor in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lidel Do you feel strongly about this nit? I ask because refactoring this leads to a similar situation we had with past refactor suggestions where the resulting code has to return multiple bools to signal when the caller should return and with what, etc... in this case needing to return 2 paths and 2 bools. If you feel strongly, I'll see what I can do. Thank you!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I refactored as requested. Hopefully you're okay with the booleans.
…-ipfs-redirects-file
|
- this function is core to all response types, does not belong to _redirects specific file - small improvements that improve readability and remove surface for bugs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed again and pushed some tweaks.
No real blockers, should be good enough for inclusion in 0.16 RC, but see the ask below.
return true, toPath, err | ||
} | ||
|
||
if rule.Status == 410 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@justincjohnson I missed these before:
- 410 and 451 are missing sharness tests
- 410 and 451 should behave similarly to what we do for 404, allowing for custom error pages to be rendered informing user why content was taken down.
- perhaps reuse
i.serve404
– rename it toi.serve4xx
and make it accept specific code as a parameter?
- perhaps reuse
coreiface.ErrResolveFailed
should not be used for them, create dedicated errors
lmk if you have time to address this before Monday, ideally we would include examples of these in the text fixture that is listed in specs (sadly the CID needs to be updated once again).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No problem. I'll get this done tomorrow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, please avoid force-push this time, will make review easier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have made the changes and pushed (not force!).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CIDs have been updated in the spec and IPIP as well.
Thanks for all the work here all! For being included in 0.16 (#9237), we'll need to have this ready for review today (2022-09-23) because the RC gets cut on 2022-09-26 Europe time. |
The changes are in and ready for review @BigLep 🙏 |
Reduce noise by moving legacy redirect logic to *redirects.go
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @johnnymatthews 👍 ❤️
Switched to v0.1.1 and pushed some final cleanup.
I believe this is good enough to ship in 0.16 RC (#9237) next week and take it for a spin in the real world.
Merging! (I'll squash, because we moved things around many times).
@lidel thanks a ton for all the work you put into this! |
Based on things provided by ipfs/kubo#8890
@justincjohnson fysa we are writing end-user docs for docs.ipfs.tech too, PR draft in ipfs/ipfs-docs#1275 |
ipfs/kubo#8890 ipfs/specs#290 This commit was moved from ipfs/kubo@bcaacdd
This PR implements ipfs/specs#290.
Details
Now that #8885 has landed, I've moved my refactored
_redirects
changes here from #8816. This is on my personal account now, so the CircleCI permission issues should be resolved. 😅@lidel, as mentioned at #8816 (comment), there are some challenges with trying to fully move
_redirects
logic out ofgateway_handler.go
as you requested. The changes in this PR aren't ready (full review not needed yet), but would you be able to take a look and let me know if you approve of how I've split code intohandleUnixfsPathResolution
andhandleNonUnixfsPathResolution
?Also, note that I've intentionally not moved 404 related functions from
gateway_handler.go
togateway_handler_unixfs__redirects.go
yet, to avoid extra PR noise.