x/pkgsite: redirect based on custom import paths

[AGWA]

What is the URL of the page with the issue?

https://pkg.go.dev/github.com/SSLMate/go-pkcs12

What is your user agent?

Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Screenshot

What did you do?

Navigated to https://pkg.go.dev/github.com/SSLMate/go-pkcs12

What did you expect to see?

Be redirected to the documentation for software.sslmate.com/src/go-pkcs12 as this is the canonical import path for the package: https://github.com/SSLMate/go-pkcs12/blob/master/pkcs12.go#L18

godoc.org exhibited the expected behavior.

What did you see instead?

I saw documentation for the package github.com/SSLMate/go-pkcs12, even though this is not the canonical import path.

[AGWA]

Another example of a package that doesn't redirect to the canonical import path: https://pkg.go.dev/github.com/golang/crypto/bcrypt

[julieqiu]

The reason is because https://pkg.go.dev/github.com/SSLMate/go-pkcs12 is showing the latest version (v0.0.0-20201103104416-57fc603b7f52) where it was still the canonical import path. If that version didn't exist on pkg.go.dev, it would redirect to pkg.go.dev/software.sslmate.com/src/go-pkcs12.

We're planning to fix this as part of #44437.

[AGWA]

Thanks @julieqiu. That version did have the canonical import path set to software.sslmate.com/src/go-pkcs12. I assume the redirection is based on the module path in go.mod rather than the canonical import path? In any case I'm glad a fix is planned.

[julieqiu]

I assume the redirection is based on the module path in go.mod rather than the canonical import path?

Yup that is correct.

I think it makes sense to support custom import paths in addition to redirecting based on the go.mod path.