go-import meta should point to final VCS host, not a redirect target #5

New issue

Open

opened 2026-05-06 01:14:12 +02:00 by heiko · 1 comment

heiko commented

2026-05-06 01:14:12 +02:00

Owner

Problem

The go-import meta tag currently points to https://git.schlittermann.de/... as the VCS URL:

<meta name="go-import" content="go.schlittermann.de/heiko/hello git https://git.schlittermann.de/heiko/hello"/>

However, git.schlittermann.de redirects (HTTP 301/302) to forgejo.schlittermann.de:

curl -sI https://git.schlittermann.de/heiko/hello
Location: https://forgejo.schlittermann.de/heiko/hello

Why this is a problem

Git does not forward credentials across redirected hosts. When a tool (like go mod download or gogogo) injects authentication for git.schlittermann.de, the credentials are dropped when Git follows the redirect to forgejo.schlittermann.de. This causes authentication failures for private repositories.

The workaround is to resolve the redirect chain first and then inject credentials targeting the final host — but this adds complexity and an extra HTTP round-trip that shouldn't be necessary.

Suggested fix

The go-import meta tag should point directly to the final, canonical VCS host:

<meta name="go-import" content="go.schlittermann.de/heiko/hello git https://forgejo.schlittermann.de/heiko/hello"/>

This way, tools and the Go toolchain connect directly to the host that actually serves Git, and credentials work without redirect resolution.

Context

Discovered while implementing private repo support in gogogo (PR gogogo#37). gogogo now works around this by resolving redirects before injecting credentials, but other tools may not.

## Problem The `go-import` meta tag currently points to `https://git.schlittermann.de/...` as the VCS URL: ```html <meta name="go-import" content="go.schlittermann.de/heiko/hello git https://git.schlittermann.de/heiko/hello"/> ``` However, `git.schlittermann.de` redirects (HTTP 301/302) to `forgejo.schlittermann.de`: ``` curl -sI https://git.schlittermann.de/heiko/hello Location: https://forgejo.schlittermann.de/heiko/hello ``` ## Why this is a problem Git does **not** forward credentials across redirected hosts. When a tool (like `go mod download` or gogogo) injects authentication for `git.schlittermann.de`, the credentials are dropped when Git follows the redirect to `forgejo.schlittermann.de`. This causes authentication failures for private repositories. The workaround is to resolve the redirect chain first and then inject credentials targeting the final host — but this adds complexity and an extra HTTP round-trip that shouldn't be necessary. ## Suggested fix The `go-import` meta tag should point directly to the final, canonical VCS host: ```html <meta name="go-import" content="go.schlittermann.de/heiko/hello git https://forgejo.schlittermann.de/heiko/hello"/> ``` This way, tools and the Go toolchain connect directly to the host that actually serves Git, and credentials work without redirect resolution. ## Context Discovered while implementing private repo support in gogogo (PR gogogo#37). gogogo now works around this by resolving redirects before injecting credentials, but other tools may not.

heiko commented

2026-05-06 01:14:57 +02:00

Author

Owner

The workaround in gogogo is in commit 8e61a60 — specifically internal/cmd/release/release.go line 983, where builder.ResolveRedirect() resolves the redirect chain before building the insteadOf credential env vars.

The workaround in gogogo is in commit [`8e61a60`](https://forgejo.schlittermann.de/heiko/gogogo/commit/8e61a60) — specifically [`internal/cmd/release/release.go` line 983](https://forgejo.schlittermann.de/heiko/gogogo/src/commit/8e61a60/internal/cmd/release/release.go#L983), where `builder.ResolveRedirect()` resolves the redirect chain before building the `insteadOf` credential env vars.