同じ名前の複数のCookieを処理する方法は？
たとえば、次のHTTPヘッダーを送信して「a」という名前のCookieを設定するアプリケーションがあったとします。
Set-Cookie: a=1;Path=/;Version=1
Set-Cookie: a=2;Path=/example;Version=1
サーバー上の/exampleにアクセスすると両方のパスが有効なので、「a」という名前の2つのCookieがあります！ブラウザはパス情報を送信しないため、2つのCookieを区別できません。
Cookie: a=2; a=1
このケースはどのように処理する必要がありますか？最初のものを選びますか？すべてのCookie値を含むリストを作成しますか？または、そのようなケースは開発者の間違いと見なされるべきですか？
同じ名前の複数のCookieが特定のリクエストURIに一致する場合、ブラウザによって選択されます。
パスが具体的であるほど、優先順位は高くなります。ただし、ドメインを含む他の属性に基づく優先順位は指定されておらず、ブラウザによって異なる場合があります。これは、「。example.org」と「www.example.org」に対して同じ名前のCookieを設定している場合、どのCookieが返されるかを確認できないことを意味します。
編集：2010年からのこの情報は古くなっているように見えますが、ブラウザは代わりに複数のCookieを送信できるようです。詳細については、@ Nateによる回答を参照してください
SitePointの記事に関する回答は完全ではありません。 RFC 6265 を参照してください（公平のために、このRFCはこの質問が投稿された後に2011年にリリースされ、以前の RFC 2965 に取って代わりました） 2000年から RFC 2109 1997年から）。
セクション 5.4 、サブセクション2には次のように記載されています。
ユーザーエージェントは、Cookieリストを次の順序でソートする必要があります。
- パスが長いCookieは、パスが短いCookieの前にリストされます。
注：すべてのユーザーエージェントがこの順序でcookie-listを並べ替えるわけではありませんが、この順序はこのドキュメントが書かれたときの一般的な慣習を反映しており、歴史的に、この順序に（誤って）依存したサーバーがありました。
セクションにこの小さな宝石もあります 4.2.2 ：
...サーバーは、シリアル化の順序に依存するべきではありません。特に、Cookieヘッダーに同じ名前（たとえば、異なるパスまたはドメイン属性で設定された）の2つのCookieが含まれている場合、サーバーはこれらのCookieがヘッダーに表示される順序に依存するべきではありません（SHOULD NOT）。
リクエストCookieの例（Cookie：a = 2; a = 1）では、Cookieがパスに設定されていることに注意してください/ example（a = 2 =）パス/（a = 1）のパスよりも長いパスがあるため、最初に行に返されます。スペックしたがって、couldで最初の値を選択するという仮定は多かれ少なかれ正しいです。
残念ながら、RFCで使用される言語は非常に具体的です。[〜＃〜] should [〜＃〜]およびSHOULD NOTという言葉を使用すると、RFCにあいまいさが生じます。これらは、必須に従うが、仕様に準拠するために必須ではないという規則を示しています。私はこれに関するRFCを非常によく理解していますが、実際のクライアントが何をするかを調べるための調査は行っていません。 HTTPクライアントとして機能する1つまたは複数のブラウザまたは他のソフトウェアが、Cookie：ヘッダーで最初に最長パスCookie（例：/ example）を送信しない可能性があります。
Cookieの値を制御する立場にあり、ソリューションを完全なものにしたい場合は、次のいずれかの方法が最適です。
別のCookie名を使用して、次のような特定のパスでオーバーライドします。
- Set-cookie：a-global = 1; Path = /; Version = 1
- Set-cookie：a-example = 2; Path =/example; Version = 1
必要なパスをCookie値自体に保存します。
- セットCookie：a = 1＆path = /; Path = /; Version = 1
- Set-cookie：a = 2＆path =/example; Path =/example; Version = 1
これらの回避策はどちらも、要求されたURLを利用可能なCookieのリストと比較することにより、目的のCookie値を選択するためにサーバー上に追加のロジックを必要とします。あまりきれいではありません。残念ながら、長いパスが短いパスのCookieを完全にオーバーライドすることを要求する先見性がRFCにありませんでした（例：あなたの例では、Cookie：a = 2only）。
私は確かに、複数のセッションIDを使用してこれを広範囲に行うアプリケーションを認識しています-そして、一貫して動作するようです。ただし、ブラウザが設定された時間/設定されたパスまたはアプリがそれぞれに一致しようとするかどうかに応じて、Cookieが一貫した順序でCookieを返すため、そうする場合、私は知りません-そして見つけるつもりはありません既存のセッションに1つ。
この慣行を避けることを強くお勧めします。
ただし、ブラウザ（およびアプリ）がこのシナリオをどのように処理するかを本当に知りたい場合は、テストリグを構築して試してみてください。
同じ名前に複数の値を設定しても問題はありません...それらが必要な場合。値に追加のコンテキストを埋め込むこともできます。
そうしない場合、両方のコンテキストが必要な場合はもちろん、異なる名前が解決策になります。
別の方法は、より具体的なパスからでも同じパス（およびドメイン）で同じCookie名を送信することです。これらの設定されたCookieの指示は、そのCookieの値を上書きします。
最も重要な部分（それらがどのように機能するか）を理解し、必要なものをいくつかの異なる方法で達成できるようになったので、あなたの質問に対する私の答えは、これは開発者の問題です。