fix(x402): default 402 challenge resource.url to https on public hosts

[bussyjd]

Summary

What changed: buildResourceURL (the 402 challenge resource.url builder in the verifier's ForwardAuth path) now uses the same scheme resolution as resolveSiteURL: default https, downgrade to http only for hosts the stack serves locally over plain HTTP (obol.stack, loopback, *.localhost/*.local); an explicit https signal (direct TLS or X-Forwarded-Proto: https) still wins for any host. The resolution is extracted into a shared resolveScheme so challenge URLs and 402-page links can never disagree again.

Why it matters: behind a TLS-terminating tunnel the ForwardAuth hop sees plaintext, so the scheme keyed off X-Forwarded-Proto alone renders http:// resource URLs whenever a route lacks the X-Forwarded-Proto: https RequestHeaderModifier. The controller's host-bound so-<name>-host routes carry that filter, but the shared-origin so-<name> routes do not — and being more path-specific for /services/<name>, they win the match even on dedicated-hostname origins. Observed live: 5 of 8 host-bound offers advertised http:// resources in their 402 challenges on https endpoints — a scheme mismatch visible to strict x402 v2 clients and discovery crawlers.

This is the verifier-side half of the correctness gap discussed in #679. It deliberately does NOT force X-Forwarded-Proto: https on shared-origin routes: those also serve genuine local plaintext traffic on obol.stack, where claiming https would be wrong in the other direction.

Risk level: low

Base branch: main

Scope

• Code

Validation

Unit tests:

go build ./... && go test ./internal/x402/ -count=1 — ok
New TestBuildResourceURL_Scheme: public host no-XFP -> https; public host
XFP=http (tunnel case) -> https; forwarded host honored; obol.stack/localhost
stay http; explicit XFP=https on local host honored; X-Forwarded-Uri preserved.

Live evidence (v0.13.0 deployment behind a Cloudflare tunnel): all 8 host-bound offers' /services/<name> challenges advertised http:// or https:// depending solely on whether a hand-authored route with the header filter happened to match; with trusted forwarded headers (the operator-side workaround) all emit https and a real x402 payment settled end-to-end ($0.01 USDC on Base, exact ledger delta). This patch makes the correct scheme the default with no per-route filters or Traefik trust configuration required.

Refs #679

https://claude.ai/code/session_014YjPMViNrZ7zBVgUQzwEKk

[bussyjd]

Subsumed by #800 (integration/v0.14.0-rc1) — this change is already folded into rc1 (0 commits not in rc1 by patch-id) and ships in the v0.14.0-rc1 pre-release. Closing to avoid an individual merge forcing an rc1 rebase; the branch is retained.

https://claude.ai/code/session_01PnhCQLz7CHuDBUhWd5xF8v

[bussyjd]

Summary

What changed: buildResourceURL (the 402 challenge resource.url builder in the verifier's ForwardAuth path) now uses the same scheme resolution as resolveSiteURL: default https, downgrade to http only for hosts the stack serves locally over plain HTTP (obol.stack, loopback, *.localhost/*.local); an explicit https signal (direct TLS or X-Forwarded-Proto: https) still wins for any host. The resolution is extracted into a shared resolveScheme so challenge URLs and 402-page links can never disagree again.

Why it matters: behind a TLS-terminating tunnel the ForwardAuth hop sees plaintext, so the scheme keyed off X-Forwarded-Proto alone renders http:// resource URLs whenever a route lacks the X-Forwarded-Proto: https RequestHeaderModifier. The controller's host-bound so-<name>-host routes carry that filter, but the shared-origin so-<name> routes do not — and being more path-specific for /services/<name>, they win the match even on dedicated-hostname origins. Observed live: 5 of 8 host-bound offers advertised http:// resources in their 402 challenges on https endpoints — a scheme mismatch visible to strict x402 v2 clients and discovery crawlers.

This is the verifier-side half of the correctness gap discussed in #679. It deliberately does NOT force X-Forwarded-Proto: https on shared-origin routes: those also serve genuine local plaintext traffic on obol.stack, where claiming https would be wrong in the other direction.

Risk level: low

Base branch: main

Scope

• Code

Validation

Unit tests:

go build ./... && go test ./internal/x402/ -count=1 — ok
New TestBuildResourceURL_Scheme: public host no-XFP -> https; public host
XFP=http (tunnel case) -> https; forwarded host honored; obol.stack/localhost
stay http; explicit XFP=https on local host honored; X-Forwarded-Uri preserved.

Live evidence (v0.13.0 deployment behind a Cloudflare tunnel): all 8 host-bound offers' /services/<name> challenges advertised http:// or https:// depending solely on whether a hand-authored route with the header filter happened to match; with trusted forwarded headers (the operator-side workaround) all emit https and a real x402 payment settled end-to-end ($0.01 USDC on Base, exact ledger delta). This patch makes the correct scheme the default with no per-route filters or Traefik trust configuration required.

Refs #679

https://claude.ai/code/session_014YjPMViNrZ7zBVgUQzwEKk

[bussyjd]

Subsumed by #800 (integration/v0.14.0-rc1) — this change is already folded into rc1 (0 commits not in rc1 by patch-id) and ships in the v0.14.0-rc1 pre-release. Closing to avoid an individual merge forcing an rc1 rebase; the branch is retained.

https://claude.ai/code/session_01PnhCQLz7CHuDBUhWd5xF8v

[bussyjd]

Summary

What changed: buildResourceURL (the 402 challenge resource.url builder in the verifier's ForwardAuth path) now uses the same scheme resolution as resolveSiteURL: default https, downgrade to http only for hosts the stack serves locally over plain HTTP (obol.stack, loopback, *.localhost/*.local); an explicit https signal (direct TLS or X-Forwarded-Proto: https) still wins for any host. The resolution is extracted into a shared resolveScheme so challenge URLs and 402-page links can never disagree again.

Why it matters: behind a TLS-terminating tunnel the ForwardAuth hop sees plaintext, so the scheme keyed off X-Forwarded-Proto alone renders http:// resource URLs whenever a route lacks the X-Forwarded-Proto: https RequestHeaderModifier. The controller's host-bound so-<name>-host routes carry that filter, but the shared-origin so-<name> routes do not — and being more path-specific for /services/<name>, they win the match even on dedicated-hostname origins. Observed live: 5 of 8 host-bound offers advertised http:// resources in their 402 challenges on https endpoints — a scheme mismatch visible to strict x402 v2 clients and discovery crawlers.

This is the verifier-side half of the correctness gap discussed in #679. It deliberately does NOT force X-Forwarded-Proto: https on shared-origin routes: those also serve genuine local plaintext traffic on obol.stack, where claiming https would be wrong in the other direction.

Risk level: low

Base branch: main

Scope

• Code

Validation

Unit tests:

go build ./... && go test ./internal/x402/ -count=1 — ok
New TestBuildResourceURL_Scheme: public host no-XFP -> https; public host
XFP=http (tunnel case) -> https; forwarded host honored; obol.stack/localhost
stay http; explicit XFP=https on local host honored; X-Forwarded-Uri preserved.

Live evidence (v0.13.0 deployment behind a Cloudflare tunnel): all 8 host-bound offers' /services/<name> challenges advertised http:// or https:// depending solely on whether a hand-authored route with the header filter happened to match; with trusted forwarded headers (the operator-side workaround) all emit https and a real x402 payment settled end-to-end ($0.01 USDC on Base, exact ledger delta). This patch makes the correct scheme the default with no per-route filters or Traefik trust configuration required.

Refs #679

https://claude.ai/code/session_014YjPMViNrZ7zBVgUQzwEKk

[bussyjd]

Subsumed by #800 (integration/v0.14.0-rc1) — this change is already folded into rc1 (0 commits not in rc1 by patch-id) and ships in the v0.14.0-rc1 pre-release. Closing to avoid an individual merge forcing an rc1 rebase; the branch is retained.

https://claude.ai/code/session_01PnhCQLz7CHuDBUhWd5xF8v

[bussyjd]

Summary

What changed: buildResourceURL (the 402 challenge resource.url builder in the verifier's ForwardAuth path) now uses the same scheme resolution as resolveSiteURL: default https, downgrade to http only for hosts the stack serves locally over plain HTTP (obol.stack, loopback, *.localhost/*.local); an explicit https signal (direct TLS or X-Forwarded-Proto: https) still wins for any host. The resolution is extracted into a shared resolveScheme so challenge URLs and 402-page links can never disagree again.

Why it matters: behind a TLS-terminating tunnel the ForwardAuth hop sees plaintext, so the scheme keyed off X-Forwarded-Proto alone renders http:// resource URLs whenever a route lacks the X-Forwarded-Proto: https RequestHeaderModifier. The controller's host-bound so-<name>-host routes carry that filter, but the shared-origin so-<name> routes do not — and being more path-specific for /services/<name>, they win the match even on dedicated-hostname origins. Observed live: 5 of 8 host-bound offers advertised http:// resources in their 402 challenges on https endpoints — a scheme mismatch visible to strict x402 v2 clients and discovery crawlers.

This is the verifier-side half of the correctness gap discussed in #679. It deliberately does NOT force X-Forwarded-Proto: https on shared-origin routes: those also serve genuine local plaintext traffic on obol.stack, where claiming https would be wrong in the other direction.

Risk level: low

Base branch: main

Scope

• Code

Validation

Unit tests:

go build ./... && go test ./internal/x402/ -count=1 — ok
New TestBuildResourceURL_Scheme: public host no-XFP -> https; public host
XFP=http (tunnel case) -> https; forwarded host honored; obol.stack/localhost
stay http; explicit XFP=https on local host honored; X-Forwarded-Uri preserved.

Live evidence (v0.13.0 deployment behind a Cloudflare tunnel): all 8 host-bound offers' /services/<name> challenges advertised http:// or https:// depending solely on whether a hand-authored route with the header filter happened to match; with trusted forwarded headers (the operator-side workaround) all emit https and a real x402 payment settled end-to-end ($0.01 USDC on Base, exact ledger delta). This patch makes the correct scheme the default with no per-route filters or Traefik trust configuration required.

Refs #679

https://claude.ai/code/session_014YjPMViNrZ7zBVgUQzwEKk

[bussyjd]

Subsumed by #800 (integration/v0.14.0-rc1) — this change is already folded into rc1 (0 commits not in rc1 by patch-id) and ships in the v0.14.0-rc1 pre-release. Closing to avoid an individual merge forcing an rc1 rebase; the branch is retained.

https://claude.ai/code/session_01PnhCQLz7CHuDBUhWd5xF8v

[bussyjd]

Summary

What changed: buildResourceURL (the 402 challenge resource.url builder in the verifier's ForwardAuth path) now uses the same scheme resolution as resolveSiteURL: default https, downgrade to http only for hosts the stack serves locally over plain HTTP (obol.stack, loopback, *.localhost/*.local); an explicit https signal (direct TLS or X-Forwarded-Proto: https) still wins for any host. The resolution is extracted into a shared resolveScheme so challenge URLs and 402-page links can never disagree again.

Why it matters: behind a TLS-terminating tunnel the ForwardAuth hop sees plaintext, so the scheme keyed off X-Forwarded-Proto alone renders http:// resource URLs whenever a route lacks the X-Forwarded-Proto: https RequestHeaderModifier. The controller's host-bound so-<name>-host routes carry that filter, but the shared-origin so-<name> routes do not — and being more path-specific for /services/<name>, they win the match even on dedicated-hostname origins. Observed live: 5 of 8 host-bound offers advertised http:// resources in their 402 challenges on https endpoints — a scheme mismatch visible to strict x402 v2 clients and discovery crawlers.

This is the verifier-side half of the correctness gap discussed in #679. It deliberately does NOT force X-Forwarded-Proto: https on shared-origin routes: those also serve genuine local plaintext traffic on obol.stack, where claiming https would be wrong in the other direction.

Risk level: low

Base branch: main

Scope

• Code

Validation

Unit tests:

go build ./... && go test ./internal/x402/ -count=1 — ok
New TestBuildResourceURL_Scheme: public host no-XFP -> https; public host
XFP=http (tunnel case) -> https; forwarded host honored; obol.stack/localhost
stay http; explicit XFP=https on local host honored; X-Forwarded-Uri preserved.

Live evidence (v0.13.0 deployment behind a Cloudflare tunnel): all 8 host-bound offers' /services/<name> challenges advertised http:// or https:// depending solely on whether a hand-authored route with the header filter happened to match; with trusted forwarded headers (the operator-side workaround) all emit https and a real x402 payment settled end-to-end ($0.01 USDC on Base, exact ledger delta). This patch makes the correct scheme the default with no per-route filters or Traefik trust configuration required.

Refs #679

https://claude.ai/code/session_014YjPMViNrZ7zBVgUQzwEKk

[bussyjd]

Subsumed by #800 (integration/v0.14.0-rc1) — this change is already folded into rc1 (0 commits not in rc1 by patch-id) and ships in the v0.14.0-rc1 pre-release. Closing to avoid an individual merge forcing an rc1 rebase; the branch is retained.

https://claude.ai/code/session_01PnhCQLz7CHuDBUhWd5xF8v

[bussyjd]

Summary

What changed: buildResourceURL (the 402 challenge resource.url builder in the verifier's ForwardAuth path) now uses the same scheme resolution as resolveSiteURL: default https, downgrade to http only for hosts the stack serves locally over plain HTTP (obol.stack, loopback, *.localhost/*.local); an explicit https signal (direct TLS or X-Forwarded-Proto: https) still wins for any host. The resolution is extracted into a shared resolveScheme so challenge URLs and 402-page links can never disagree again.

Why it matters: behind a TLS-terminating tunnel the ForwardAuth hop sees plaintext, so the scheme keyed off X-Forwarded-Proto alone renders http:// resource URLs whenever a route lacks the X-Forwarded-Proto: https RequestHeaderModifier. The controller's host-bound so-<name>-host routes carry that filter, but the shared-origin so-<name> routes do not — and being more path-specific for /services/<name>, they win the match even on dedicated-hostname origins. Observed live: 5 of 8 host-bound offers advertised http:// resources in their 402 challenges on https endpoints — a scheme mismatch visible to strict x402 v2 clients and discovery crawlers.

This is the verifier-side half of the correctness gap discussed in #679. It deliberately does NOT force X-Forwarded-Proto: https on shared-origin routes: those also serve genuine local plaintext traffic on obol.stack, where claiming https would be wrong in the other direction.

Risk level: low

Base branch: main

Scope

• Code

Validation

Unit tests:

go build ./... && go test ./internal/x402/ -count=1 — ok
New TestBuildResourceURL_Scheme: public host no-XFP -> https; public host
XFP=http (tunnel case) -> https; forwarded host honored; obol.stack/localhost
stay http; explicit XFP=https on local host honored; X-Forwarded-Uri preserved.

Live evidence (v0.13.0 deployment behind a Cloudflare tunnel): all 8 host-bound offers' /services/<name> challenges advertised http:// or https:// depending solely on whether a hand-authored route with the header filter happened to match; with trusted forwarded headers (the operator-side workaround) all emit https and a real x402 payment settled end-to-end ($0.01 USDC on Base, exact ledger delta). This patch makes the correct scheme the default with no per-route filters or Traefik trust configuration required.

Refs #679

https://claude.ai/code/session_014YjPMViNrZ7zBVgUQzwEKk

[bussyjd]

Subsumed by #800 (integration/v0.14.0-rc1) — this change is already folded into rc1 (0 commits not in rc1 by patch-id) and ships in the v0.14.0-rc1 pre-release. Closing to avoid an individual merge forcing an rc1 rebase; the branch is retained.

https://claude.ai/code/session_01PnhCQLz7CHuDBUhWd5xF8v

[bussyjd]

Summary

What changed: buildResourceURL (the 402 challenge resource.url builder in the verifier's ForwardAuth path) now uses the same scheme resolution as resolveSiteURL: default https, downgrade to http only for hosts the stack serves locally over plain HTTP (obol.stack, loopback, *.localhost/*.local); an explicit https signal (direct TLS or X-Forwarded-Proto: https) still wins for any host. The resolution is extracted into a shared resolveScheme so challenge URLs and 402-page links can never disagree again.

Why it matters: behind a TLS-terminating tunnel the ForwardAuth hop sees plaintext, so the scheme keyed off X-Forwarded-Proto alone renders http:// resource URLs whenever a route lacks the X-Forwarded-Proto: https RequestHeaderModifier. The controller's host-bound so-<name>-host routes carry that filter, but the shared-origin so-<name> routes do not — and being more path-specific for /services/<name>, they win the match even on dedicated-hostname origins. Observed live: 5 of 8 host-bound offers advertised http:// resources in their 402 challenges on https endpoints — a scheme mismatch visible to strict x402 v2 clients and discovery crawlers.

This is the verifier-side half of the correctness gap discussed in #679. It deliberately does NOT force X-Forwarded-Proto: https on shared-origin routes: those also serve genuine local plaintext traffic on obol.stack, where claiming https would be wrong in the other direction.

Risk level: low

Base branch: main

Scope

• Code

Validation

Unit tests:

go build ./... && go test ./internal/x402/ -count=1 — ok
New TestBuildResourceURL_Scheme: public host no-XFP -> https; public host
XFP=http (tunnel case) -> https; forwarded host honored; obol.stack/localhost
stay http; explicit XFP=https on local host honored; X-Forwarded-Uri preserved.

Live evidence (v0.13.0 deployment behind a Cloudflare tunnel): all 8 host-bound offers' /services/<name> challenges advertised http:// or https:// depending solely on whether a hand-authored route with the header filter happened to match; with trusted forwarded headers (the operator-side workaround) all emit https and a real x402 payment settled end-to-end ($0.01 USDC on Base, exact ledger delta). This patch makes the correct scheme the default with no per-route filters or Traefik trust configuration required.

Refs #679

https://claude.ai/code/session_014YjPMViNrZ7zBVgUQzwEKk

[bussyjd]

Subsumed by #800 (integration/v0.14.0-rc1) — this change is already folded into rc1 (0 commits not in rc1 by patch-id) and ships in the v0.14.0-rc1 pre-release. Closing to avoid an individual merge forcing an rc1 rebase; the branch is retained.

https://claude.ai/code/session_01PnhCQLz7CHuDBUhWd5xF8v

[bussyjd]

Summary

What changed: buildResourceURL (the 402 challenge resource.url builder in the verifier's ForwardAuth path) now uses the same scheme resolution as resolveSiteURL: default https, downgrade to http only for hosts the stack serves locally over plain HTTP (obol.stack, loopback, *.localhost/*.local); an explicit https signal (direct TLS or X-Forwarded-Proto: https) still wins for any host. The resolution is extracted into a shared resolveScheme so challenge URLs and 402-page links can never disagree again.

Why it matters: behind a TLS-terminating tunnel the ForwardAuth hop sees plaintext, so the scheme keyed off X-Forwarded-Proto alone renders http:// resource URLs whenever a route lacks the X-Forwarded-Proto: https RequestHeaderModifier. The controller's host-bound so-<name>-host routes carry that filter, but the shared-origin so-<name> routes do not — and being more path-specific for /services/<name>, they win the match even on dedicated-hostname origins. Observed live: 5 of 8 host-bound offers advertised http:// resources in their 402 challenges on https endpoints — a scheme mismatch visible to strict x402 v2 clients and discovery crawlers.

This is the verifier-side half of the correctness gap discussed in #679. It deliberately does NOT force X-Forwarded-Proto: https on shared-origin routes: those also serve genuine local plaintext traffic on obol.stack, where claiming https would be wrong in the other direction.

Risk level: low

Base branch: main

Scope

• Code

Validation

Unit tests:

go build ./... && go test ./internal/x402/ -count=1 — ok
New TestBuildResourceURL_Scheme: public host no-XFP -> https; public host
XFP=http (tunnel case) -> https; forwarded host honored; obol.stack/localhost
stay http; explicit XFP=https on local host honored; X-Forwarded-Uri preserved.

Live evidence (v0.13.0 deployment behind a Cloudflare tunnel): all 8 host-bound offers' /services/<name> challenges advertised http:// or https:// depending solely on whether a hand-authored route with the header filter happened to match; with trusted forwarded headers (the operator-side workaround) all emit https and a real x402 payment settled end-to-end ($0.01 USDC on Base, exact ledger delta). This patch makes the correct scheme the default with no per-route filters or Traefik trust configuration required.

Refs #679

https://claude.ai/code/session_014YjPMViNrZ7zBVgUQzwEKk

[bussyjd]

Subsumed by #800 (integration/v0.14.0-rc1) — this change is already folded into rc1 (0 commits not in rc1 by patch-id) and ships in the v0.14.0-rc1 pre-release. Closing to avoid an individual merge forcing an rc1 rebase; the branch is retained.

https://claude.ai/code/session_01PnhCQLz7CHuDBUhWd5xF8v