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