Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

[インデックス 18170] ファイルの概要

net/http/cookiejarパッケージは、HTTPクッキーの管理を扱うGo言語の標準ライブラリの一部です。このパッケージは、Webブラウザがクッキーを処理する方法を模倣し、HTTPリクエストとレスポンス間でクッキーの状態を維持するためのJarインターフェースを提供します。jar.goファイルは、このパッケージの主要な実装と、クッキーのドメインマッチングにおいて重要な役割を果たすPublicSuffixListインターフェースの定義を含んでいます。

コミット

net/http/cookiejar: PublicSuffixにおけるドメインのフォーマットを文書化

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/eb93f86275870bfe7d2b71d244df9ea87320e185

元コミット内容

    net/http/cookiejar: document format of domain in PublicSuffix
    
    Document what values a PublicSuffixList must accept as
    a domain in a call to PublicSuffix.
    
    R=bradfitz, nigeltao
    CC=golang-codereviews
    https://golang.org/cl/47560044

変更の背景

このコミットの背景には、net/http/cookiejarパッケージ内のPublicSuffixListインターフェースが提供するPublicSuffixメソッドのドキュメントが不明確であったという問題があります。以前のドキュメントでは、PublicSuffixメソッドに渡されるdomain引数の形式について、IPアドレスの扱い、先頭および末尾のドットの有無、大文字・小文字の区別、国際化ドメイン名(IDN)やPunycodeの扱いなど、いくつかの重要な側面が「TODO」として残されており、明確に指定されていませんでした。

このようなドキュメントの曖昧さは、PublicSuffixListインターフェースを実装する開発者にとって混乱を招く可能性がありました。インターフェースの契約が曖昧であると、異なる実装間で期待される動作に不一致が生じ、予期せぬバグや互換性の問題を引き起こす可能性があります。特に、HTTPクッキーのセキュリティとプライバシーにおいて、パブリックサフィックスの正確な特定は、悪意のあるサイトが他のドメインのクッキーを不正に設定する「Supercookie」攻撃を防ぐ上で極めて重要です。

このコミットは、この曖昧さを解消し、PublicSuffixメソッドが受け入れるdomain引数の正確なフォーマットを明確に文書化することを目的としています。これにより、インターフェースの契約が強化され、PublicSuffixListの実装がより堅牢で予測可能になり、Go言語のネットワークスタック全体の信頼性が向上します。

前提知識の解説

  • net/http/cookiejarパッケージ: Go言語の標準ライブラリの一部であり、HTTPクッキーを管理するための機能を提供します。Webブラウザがクッキーを処理する方法を模倣し、HTTPリクエストとレスポンス間でクッキーの状態を維持するために使用されます。これにより、セッション管理やユーザー認証などのWebアプリケーションの基本的な機能が実現されます。

  • PublicSuffixListインターフェース: このインターフェースは、ドメイン名から「パブリックサフィックス(Public Suffix)」を特定するためのPublicSuffixメソッドを定義します。パブリックサフィックスとは、com, co.uk, github.ioなどのように、組織や個人が自由にドメイン名を登録できるドメインの最上位部分を指します。例えば、example.comではcomがパブリックサフィックスであり、example.example.co.ukではco.ukがパブリックサフィックスです。

  • パブリックサフィックス(Public Suffix): インターネット上で登録可能なドメイン名の最下位レベルの部分です。これは、ドメインレジストリによって管理され、ユーザーが直接登録できるドメイン名(例: example.comexample部分)とは異なります。パブリックサフィックスリスト(Public Suffix List, PSL)は、これらのサフィックスの包括的なリストであり、Mozillaによって維持されています。このリストは、ブラウザや他のネットワークソフトウェアが、クッキーのセキュリティ境界を正しく判断するために使用されます。例えば、example.comcomのクッキーを設定できないようにすることで、malicious.comexample.comのクッキーを盗むことを防ぎます。

  • Punycode: 国際化ドメイン名(IDN)をASCII文字のみで表現するためのエンコーディング方式です。IDNは、日本語、中国語、アラビア語などの非ASCII文字を含むドメイン名ですが、DNSシステムはASCII文字しか扱えないため、Punycodeに変換されます。例えば、日本語の「ドメイン.jp」はPunycodeで「xn--eckp3amb0a.jp」のようになります。これにより、世界中の言語でドメイン名を使用できるようになります。

  • IDN (Internationalized Domain Name): ASCII文字以外の文字(例: 日本語、アラビア語、キリル文字など)を含むドメイン名です。ユーザーはこれらのドメイン名を母国語で入力できますが、内部的にはPunycodeに変換されて処理されます。

技術的詳細

このコミットの技術的な詳細は、インターフェースの契約を明確にすることの重要性に集約されます。PublicSuffixListインターフェースのPublicSuffixメソッドは、ドメイン名を引数として受け取り、そのドメインのパブリックサフィックスを返します。しかし、以前のドキュメントでは、このdomain引数がどのような形式で渡されるべきか、また返される値がどのような形式であるべきかについて、以下のような曖昧さがありました。

  1. IPアドレスの扱い: domainがIPアドレスである場合、PublicSuffixメソッドはどのように振る舞うべきか?パブリックサフィックスはドメイン名に適用される概念であり、IPアドレスには適用されません。
  2. 先頭および末尾のドット: domain.で始まる、または終わる場合、どのように処理すべきか?ドメイン名には通常、先頭や末尾にドットは含まれません。
  3. 大文字・小文字の区別: domainの大文字・小文字は区別されるべきか?ドメイン名は通常、大文字・小文字を区別しませんが、処理の標準化が必要です。
  4. IDN/Punycode: domainが国際化ドメイン名(IDN)である場合、Punycodeに変換された形式で渡されるべきか、それとも元のIDN形式で渡されるべきか?Punycodeへの変換は、ドメイン名処理の一般的なステップです。

これらの疑問は、PublicSuffixListインターフェースを実装する際に、開発者が独自の解釈をする余地を与えてしまい、結果として異なる実装間で一貫性のない動作を引き起こす可能性がありました。特に、クッキーのセキュリティとプライバシーに関わる部分であるため、厳密な仕様が求められます。

このコミットでは、これらの曖昧さを解消するために、PublicSuffixメソッドのドキュメントに以下の明確な仕様を追加しました。

  • Domain is a lowercase punycoded domain name (not an IP address) without leading or trailing dots.

    • これは、PublicSuffixメソッドに渡されるdomain引数が、小文字に変換されPunycodeエンコードされたドメイン名であるべきであり、IPアドレスであってはならず先頭や末尾にドットを含まないことを明確にしています。これにより、入力の正規化に関する責任が明確になります。
  • The returned value is in the same form.

    • これは、PublicSuffixメソッドが返す値も、入力と同じ形式(小文字、Punycodeエンコード、ドットなし)であることを保証します。これにより、出力の形式も予測可能になり、インターフェースの利用者にとって扱いやすくなります。

この変更により、PublicSuffixListインターフェースの実装者は、入力と出力の形式について明確なガイドラインを得ることができます。これにより、実装間の互換性が向上し、net/http/cookiejarパッケージ全体の堅牢性と信頼性が高まります。例えば、PublicSuffixの実装は、入力ドメインがすでにPunycode化され、小文字であり、ドットがないことを前提とできるため、これらの前処理を行う必要がなくなります。これは、インターフェースの責任分担を明確にし、コードの複雑さを軽減する効果もあります。

コアとなるコードの変更箇所

--- a/src/pkg/net/http/cookiejar/jar.go
+++ b/src/pkg/net/http/cookiejar/jar.go
@@ -34,9 +34,9 @@ import (
 type PublicSuffixList interface {
 	// PublicSuffix returns the public suffix of domain.
 	//
-	// TODO: specify which of the caller and callee is responsible for IP
-	// addresses, for leading and trailing dots, for case sensitivity, and
-	// for IDN/Punycode.
+	// Domain is a lowercase punycoded domain name (not an IP address)
+	// without leading or trailing dots. The returned value is in the
+	// same form.
 	PublicSuffix(domain string) string
 
 	// String returns a description of the source of this public suffix

コアとなるコードの解説

変更はsrc/pkg/net/http/cookiejar/jar.goファイル内のPublicSuffixListインターフェースの定義部分にあります。具体的には、PublicSuffixメソッドのコメントが修正されています。

  • 変更前:

    // TODO: specify which of the caller and callee is responsible for IP
    // addresses, for leading and trailing dots, for case sensitivity, and
    // for IDN/Punycode.
    

    このコメントは、PublicSuffixメソッドのdomain引数の形式に関する責任の所在が不明確であることを示していました。IPアドレス、ドット、大文字・小文字、IDN/Punycodeの扱いについて、呼び出し元と実装者のどちらが処理すべきかが明記されていませんでした。これは、インターフェースの利用者と実装者の間で誤解を生む可能性がありました。

  • 変更後:

    // Domain is a lowercase punycoded domain name (not an IP address)
    // without leading or trailing dots. The returned value is in the
    // same form.
    

    この新しいコメントは、PublicSuffixメソッドのdomain引数に期待される形式を明確に定義しています。

    • lowercase: ドメイン名は小文字である必要があります。これにより、大文字・小文字の区別に関する曖昧さが解消され、正規化された入力が期待されます。
    • punycoded domain name: ドメイン名はPunycodeエンコードされた形式である必要があります。これにより、IDNの扱いが明確になり、PublicSuffixの実装はPunycode変換の責任を負う必要がなくなります。
    • (not an IP address): ドメイン名はIPアドレスであってはなりません。IPアドレスの処理はPublicSuffixの責任範囲外であることが示され、インターフェースのスコープが明確になります。
    • without leading or trailing dots: ドメイン名の先頭や末尾にドットが含まれていてはなりません。これにより、ドットの処理に関する曖昧さが解消され、クリーンな入力が期待されます。
    • The returned value is in the same form.: PublicSuffixメソッドが返すパブリックサフィックスも、入力と同じ形式(小文字、Punycodeエンコード、ドットなし)であることを保証します。これにより、インターフェースの出力も予測可能で一貫性のあるものとなります。

この変更は、コードの動作自体を変更するものではなく、インターフェースの契約を明確にするためのドキュメントの改善です。しかし、これによりPublicSuffixListインターフェースの実装者は、より正確で堅牢なコードを書くことができるようになり、パッケージ全体の信頼性が向上します。これは、API設計において、インターフェースの契約を明確に定義することの重要性を示す良い例です。

関連リンク

参考にした情報源リンク

  • Go言語の公式ドキュメント
  • Public Suffix Listの公式ウェブサイト
  • RFC 3492 (Punycode)