Skip to content

Align publisher rewriting and first-party signing request schemes #1447

Open

Description

@prk-Jr

Description

Publisher URL rewriting derives its scheme from TLS metadata and forwarded headers, then defaults to HTTP. RequestInfo::from_request does not consult an explicit request URI scheme. In contrast, /first-party/sign prefers req.uri().scheme_str(), so rewriting and signing can disagree for the same request.

This is a follow-up to PR #1413, requested in #1413 (review). It also affects requests with an explicit Host and is intentionally outside that host-authority fix.

Steps to reproduce

  1. Construct a publisher document request with URI https://publisher.example.com/page, no TLS fields in ClientInfo, and no surviving forwarded scheme headers.
  2. Resolve RequestInfo::from_request: its scheme is http despite the explicit HTTPS URI scheme.
  3. Process HTML containing https://origin.example.com/article: rewriting uses http://publisher.example.com/article.
  4. With origin.example.com in proxy.allowed_domains, send a signing request whose own URI is https://publisher.example.com/first-party/sign with JSON payload {"url":"//origin.example.com/article"} and the same absent TLS/forwarded metadata. /first-party/sign uses the explicit request URI scheme to normalize that protocol-relative target to HTTPS. An explicitly schemed target would bypass this particular scheme decision.

The PR reviewer also reproduced this with HTTP/2 :scheme https on an Axum build with HTTP/2 enabled. A TLS terminator forwarding h2c to Viceroy without surviving scheme metadata can expose the same issue. The stock Axum dev server currently supports HTTP/1 only; enabling HTTP/2 is not a prerequisite for the absolute-form unit reproduction above.

Expected behavior

Define one scheme policy shared by publisher rewriting and first-party signing. Preserve authoritative adapter TLS metadata and document the trust and precedence of explicit URI schemes and forwarded signals. HTTPS requests should not gain HTTP links solely because the transport after TLS termination is plaintext.

Affected area

HTML processing / JS injection; Fastly runtime.

Version

Observed in PR #1413 at b23cf89. Existing Host-bearing requests are affected too.

Done when

  • Publisher rewriting and /first-party/sign use a consistent, documented scheme policy.
  • Tests cover absolute HTTPS URIs without TLS/forwarded metadata, origin-form HTTP requests, trusted TLS metadata, forwarded-header sanitization, and conflicting scheme signals.
  • Regression coverage demonstrates the TLS-terminated h2c case without claiming stock Axum supports HTTP/2.
  • Adapter behavior and operator guidance explain which scheme signals are trusted.

Activity

  1. self-assigned this
    on Oct 24, 2026
  2. added theissue type on Oct 24, 2026
  3. added a commit that references this issue on Oct 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions