Web からデータをスクレイピングする趣味のプロジェクトの一環として、Cookie の処理を抽象化する何かを書いています。Cookie の処理方法を定義するRFC 6265を追跡しましたが、より頻繁に、より詳細に読むほど、混乱していきます。
- これが必要なものを定義するための適切な文書であることを誰か確認してください。
- ドキュメントのセクション 5.3には、Cookie が保存するフィールドがリストされています。Cookie の例を提供するソースはどこにありますか。
- ドキュメントのセクション 5.1.4にある、「 Cookie のデフォルト パスを計算する」方法を説明しているアルゴリズムに少し困惑しています。インターネット上のさまざまな情報源を読んだ後、ヘッダーに PATH が指定されていない場合は default-path を Cookie に保存する必要があり、セクション 5.1.4 で言及されている request-uri は、作成されたリソースの ID であると想定しています。 Cookie: ヘッダーを受信したときに返されます。誰かがこれを確認したり、私を修正したりできますか?
- セクション5.1.4 のデフォルト パス アルゴリズムには、「/」文字で始まらない URI パスを処理する方法が説明されているため、さらに混乱しています。ホスト (またはポート) と url-path の間の「/」は、url-path の一部ではないことを示します". (rfc1738 のヘッダーには、rfc4248 および rfc4266 によって廃止されたと書かれていますが、それぞれ telnet および gopher スキームの URL が記述されているため、私は http(s) URL にのみ関心があるため、安全に無視できると信じています。 .) 私が見る限り、PATH 属性のない Cookie が http/https スキームを持つリソースと共に送信される場合、Cookie はそのパス属性を「/」に設定します。 http/https スキームが後で要求された場合、要求パスも "/" で始まらないため、Cookie はパス一致せず、要求に含まれません。これはばかげているようです。誤解した？
ドメイン マッチング ルールのポイントは、サイトがそのサイト自体またはそのサブドメインにのみ送り返される Cookie を指定できるようにすることだと思いますが、パス マッチング ルールが何をすべきかよくわかりません。おそらく、誰かが愚かだがわかりやすい一文の説明を提供できれば、私は混乱を自分で解決できるでしょうか?
どうもありがとう。