レッスン 4
ログと API での URL デバッグ
解析されたコンポーネントを使って、リダイレクト、署名、キャッシュキー、トラッキングリンクをデバッグします。
本番で URL バグが現れると、完全な文字列はしばしばノイズが多いです。まずパースし、コンポーネントを比較してください。
リダイレクトバグ
リダイレクトでは次を確認してください。
- スキームとホスト
- 末尾スラッシュの有無を含むパス
- エンコードされた URL を含むクエリ値
- サーバーに届かないフラグメント値
OAuth リダイレクトバグは、ネストされた URL の中に隠れることが多いです。
redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback%3Fnext%3D%252Fbilling
1 層ずつデコードしてください。一度にすべてデコードすると、どの層がどの区切り文字を所有するかが隠れることがあります。
署名バグ
署名付き URL では次を比較してください。
- パラメータの順序
- パーセントエンコーディング
- 含まれるフィールドと除外されるフィールド
- タイムスタンプと有効期限の値
- ホストとパスの大文字小文字規則
署名者と検証者は、同じ方法で URL を正規化する必要があります。
キャッシュバグ
キャッシュは次の URL を異なるものとして扱う場合があります。
?a=1&b=2
?b=2&a=1
または同じキャッシュキーに正規化する場合もあります。CDN、プロキシ、アプリケーション層がどの規則を使うかを知ってください。
実践的ワークフロー
- 観測されたとおりに元の URL を正確に保存する。
- コンポーネントにパースする。
- 検査している層でのみ値をデコードする。
- 期待値と実際のコンポーネントを比較する。
- 明示的な規則で URL を再構築する。
目的は URL をきれいにすることではありません。受信側システムが期待する意味を保持することです。