The Gonum project uses a Hugo site hosted by Netlify. We would like to be able to redirect users to relevant pkg.go.dev pages when they browse to one of our packages, say https://gonum.org/v1/mat. Currently this leave a user at the site’s 404 landing page.
After reading URL redirect / forwarding I tried putting Netlify redirects in static/_redirects, doing exactly the right thing for users wanting documentation, but it appears to have broken go get since the redirect happens before the meta tags are served.
Is there a way to have both of these features; 1. redirect to pkg.go.dev/pkg/import/path but also 2. serve the go-import and go-source meta tags?
Hello @kortschak
The official Hugo Documentation uses a Custom Output Format for Netlify redirects.
Have a look at the source:
1 Like
Thanks. The redirection is not a problem, in that it works, but it prevents Go build tools from seeing necessary meta-data.
Right. Well in that case I misread your first post, since you referenced an outdated forum topic.
A casual search wields a few articles regarding redirects, go-import and go-source metas.
Here are some:
Setting up go get redirect for your own packages
Vanity import paths in Go
Not sure how Hugo could handle a redirect to keep those tags.
Perhaps people like @moorereason or @bep can help you more.
Neither of these handle the issue; the OP correctly describes the issue in that it talks about wanting to redirect to the pkg.go.dev pages for the Go documentation, but also provide the necessary meta tags for the go get source pulls needed for building packages. As I wrote in the original, I can get redirects to work, but they break the go-source and go-imports meta tags which we already had in place.
I have solved the problem by a conditional redirect using JS.
AFAIK, Netlify redirects happen at the HTTP layer, so there’s no opportunity to send HTML with meta tags.
Unless you want to generate a page for every /v1/* target, a Javascript solution is probably the best you can do. However, putting that Javascript into your 404 template doesn’t seem right. Does Netlify reply with a 404 status code? I would recommend creating a special v1-redirect page and use Netlify rewrites to render all /v1/* requests with that page. Put your Javascript redirect code in that page.
Update with a little trivia: go get doesn’t require a 200 status code response. Didn’t know that! So even a 404 or 301 (or 500!) response with an HTML body would work. I don’t think Netlify will let you do that with their redirect mechanism, but it’s interesting nonetheless. In all my years, I don’t think I’ve ever considered sending a body on a 301 response.
AFAIK, Netlify redirects happen at the HTTP layer, so there’s no opportunity to send HTML with meta tags.
Yes, this is exactly the issue.
I would recommend creating a special v1-redirect page and use Netlify rewrites to render all /v1/* requests with that page. Put your Javascript redirect code in that page.
Those pages would also need to have the go-source and go-import meta tags. The 404 approach that we’ve taken works, largely because of the behaviour that’s required for Go source retrieval. So unless an obviously better solution comes along, we’ll probably stay with this.
However had you really looked into my original reply above, you might have found out that by defining a template for a Custom Output Format for Redirects, it is possible to pass what you need through a template for Netlify server side redirects.
For completeness, it’s worth noting that redirects were in place for a brief period briefly (constructed locally rather than using Custom Output Formats since Go build tools make that easier). This change was backed out because it broke source distribution as noted above. Using Cutom Output Formats to generate the redirects would have had the same effect.
I think the Netlify rewrites (not redirects) could work for you since they will send an HTML body. It’s essentially the same logic as Netlify’s 404 feature (all 404 responses render your 404 template). I would personally not want to use the 404 response for this. I’d rather have a separate page that does the HTML/meta redirect with a 200 response.
But that’s not a hill worth dying on.
Thanks. That is worth looking into. Presumably that would require a two step process, 1. add the jump-to-pkg.go.dev page with the logic we currently have in the 404 page and 2. do the rewrite. Is this correct?
BTW Is there a specific reason to be opposed to using the 404 page? (my background is not in web dev in any way).
Correct.
It’s the principle of the matter. That’s not what 404 responses are for.
Fair enough. I’ll look into it since it doesn’t look like a huge change from what we already have. Thanks.