自サーバーの公開識別子（発行者識別子、リソース識別子、callback の基点 URL など）を、リクエストの Host ヘッダや X-Forwarded-Proto からその都度導出する実装は、相手がその値を「別の応答で受け取った値と厳密な文字列一致で照合する」契約には使えない。

なぜ壊れるか

同じ値を返す応答が複数あり、それぞれ別の経路で届くときに導出元がズレる。例: メタデータ取得は外向きロードバランサー経由でプロトコルヘッダも付くが、別の応答は内部ホスト名・平文で届く。このとき広告値と実際の値がスキーム・ホスト・ポートで分岐し、厳密一致検証をするクライアントが正しい応答まで破棄する。規格が「正規化しない単純文字列比較」を要求する場合、末尾スラッシュや既定ポートの有無だけでも不一致になる。

判断基準

• 相手が厳密一致で照合する値は、起動時に確定する単一の正規値（設定値）として持ち、すべての応答へ加工せず同じ文字列を渡す。
• リクエスト由来の導出は、自分の応答内で閉じる相対リンクなど、厳密一致契約の外に限定する。
• 移行期は設定値があればそれ、無ければ従来の導出という opt-in にし、本番・ステージングでは必須設定としてデプロイ手順に明記する。設定値が間違っていれば全クライアントが一斉に壊れるので、値は外向き URL と完全一致させる。
• 逆に、契約を強める変更（広告フラグを true にする等）は、それまでリスクが顕在化していなかった導出のゆらぎをハードフェイルに変える。既存の導出ロジックを「今まで動いていた」で通さず、契約を強める変更と同時に固定化する。

検証

比較される2つの応答を、Host・プロトコルヘッダ・ポートを意図的に違えた別経路で取得し、両方の値が単純文字列一致するテストを置く。全応答に同じ外向きホストを与えるテストだけでは、この経路差を検知できない。