問題タブ [rfc6265]

rfc 6265 準拠のブラウザーのリストを探しています。私はグーグルさんに尋ねましたが、どうやらこれは簡単な答えではありません。

ありがとう！

特定のCookieドメインが特定のホスト名と一致するかどうかを確認する簡単な方法を実装しようとしています。

これを行うために、RFC 6265 のセクション 5.1.3 で定義されているドメイン一致条件を実装します。

定義された 2 つの一致条件の 2 番目は、3 つのサブ条件が適用されるマルチパート条件です。

次のすべての条件が成り立ちます。

• ドメイン文字列は、文字列のサフィックスです。
• ドメイン文字列に含まれない文字列の最後の文字は、%x2E (".") 文字です。
• 文字列はホスト名です (つまり、IP アドレスではありません)。

明確にするために、上記の引用テキストが「文字列」を参照する場合、それは Cookie のドメイン値を参照しており、上記の引用テキストが「ドメイン名」を参照する場合は、Cookie が送信されるホストのドメイン名を参照しています。送信される場合があります。

これら 3 つのサブ条件のうち、1 番目と 3 番目は非常に明確です。私が混乱しているのは、秒の文言です。

「example.com」の Cookie ドメインは「example.com」のみに一致し、「.example.com」の Cookie ドメインは「<anything>.example.com」に一致することは知っています。私の推測では、この広範なサブドメイン マッチングの概念を参照する場合、2 番目のサブ条件の上にあると思われますが、言葉遣いを考えると確信が持てません。

この 2 番目のサブ条件を平易な技術英語に翻訳できる人はいますか?

現在、set-cookie ヘッダーの構文に関するRCF 6265 の章4.1.1を読みました。本文中の 4.1.1:

文法のリストには、次のエントリがあります。

私の意見では、JWT を Cookie に保存することは可能ですが、読み続けていると、このフィールドに関するドキュメントが見つかりませんでした。ウィキペディアでも、このフィールドは見つかりませんでした。

私の意見は間違っていますか？または、JWT (JWE、JWS) を Cookie に保存することは可能ですか? PHP set_cookie()-Methodでは、 この「トークン」フィールドも見つからないためです。または、トークンを Cookie に保存し、JWT を set_cookie()-Method の値に設定することもベスト プラクティスですか?

Web からデータをスクレイピングする趣味のプロジェクトの一環として、Cookie の処理を​​抽象化する何かを書いています。Cookie の処理方法を定義するRFC 6265を追跡しましたが、より頻繁に、より詳細に読むほど、混乱していきます。

1. これが必要なものを定義するための適切な文書であることを誰か確認してください。
2. ドキュメントのセクション 5.3には、Cookie が保存するフィールドがリストされています。Cookie の例を提供するソースはどこにありますか。
3. ドキュメントのセクション 5.1.4にある、「 Cookie のデフォルト パスを計算する」方法を説明しているアルゴリズムに少し困惑しています。インターネット上のさまざまな情報源を読んだ後、ヘッダーに PATH が指定されていない場合は default-path を Cookie に保存する必要があり、セクション 5.1.4 で言及されている request-uri は、作成されたリソースの ID であると想定しています。 Cookie: ヘッダーを受信したときに返されます。誰かがこれを確認したり、私を修正したりできますか?
4. セクション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 を指定できるようにすることだと思いますが、パス マッチング ルールが何をすべきかよくわかりません。おそらく、誰かが愚かだがわかりやすい一文の説明を提供できれば、私は混乱を自分で解決できるでしょうか?

どうもありがとう。