“Masquerade” helps you to host your Go modules behind your own domain.
When I tagged
v2, I had to investigate a problem where the new major version did not show up on the official Go package database on pkg.go.dev.
After some research, I discovered that the package database was using data from the official module proxy on proxy.golang.org.
When working with Go modules, the
go command may download module source code from a module proxy rather than from a version control system.
While downloading a module from a proxy is often faster, connecting directly to a repository is necessary if the module is not in the proxy’s cache.
sequenceDiagram go get->>+proxy.golang.org: Fetch module source proxy.golang.org-->>-go get: Module not found go get->>+github.com: Fetch module source github.com-->>-go get: Module source opt When the module was not found proxy.golang.org->>+github.com: Fetch module source github.com-->>-proxy.golang.org: Module source end
Since there was no obvious problem with my module or the Git repository, I wrote a small web server on
go.eigsys.de that would help me intercept the HTTP requests sent by
github.com to better understand what went wrong.
The web server also collects anonymous request statistics to determine if there is a potential problem with a new tag.
No personally identifiable information is stored or analyzed.
And to make life a little easier, it redirects you to the project’s website (as configured on GitHub) when you open a
go.eigsys.de link in your browser.
I published the web server source code on GitHub:
By the way, if you’re wondering what went wrong with
gin-cachecontrol: I finally figured out that my
go.mod file was missing the
/v2 suffix in the module declaration.