Johannes Eiglsperger

Custom Go module server

2 min read

“Masquerade” helps you to host your Go modules behind your own domain.

When I tagged gin-cachecontrol with 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 proxy.golang.org to 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.