FULL PRODUCT VERSION :
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) Client VM (build 21.0-b17, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
The "Set-Cookie" HTTP response headers with a data structure of
Map<String, List<String>> stores the cookies' list in a reversed sequence which will causes wrong cookie maintenance in CookieManager that may result in a cookie authentication validation failure.
for instance, the current time is Mon, 10-Jan-2011 01:41:57 GMT and the right sequence is:

grs=firstgrs; path=/; secure
grs=secondgrs; path=/; secure
ginger=deleted; expires=Mon, 10-Jan-2011 00:47:17 GMT; path=/; domain=<some domain>; secure
ginger=valueofginger; path=/; domain=<some domain>; secure
sesame=valueofsesame; expires=Tue, 10-Jan-2012 20:00:00 GMT; path=/; domain=<some domain>; secure

Which means the second "grs" is the true one and "ginger" should be deleted at first then reassigned a new value. So the next request should be with cookies:
grs=secondgrs; ginger=valueofginger; sesame=valueofsesame

BUT, in the HttpURLConnection's headers the "Set-Cookie" list is stored in a reversed sequence:

sesame=valueofsesame; expires=Tue, 10-Jan-2012 20:00:00 GMT; path=/; domain=<some domain>; secure
ginger=valueofginger; path=/; domain=<some domain>; secure
ginger=deleted; expires=Mon, 10-Jan-2011 00:47:17 GMT; path=/; domain=<some domain>; secure
grs=secondgrs; path=/; secure
grs=firstgrs; path=/; secure

That causes wrong cookies added into the next request as:
sesame=valueofsesame; grs=firstgrs; path=/; secure
Thus, "ginger" is deleted and "grs" is overwritten to be a dummy value.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Step 1: Construct a web action that at first sends several cookies with duplicated key and different values(such as dummy value or expires).
Step 2: Send HTTP request use HttpURLConnection and CookieManger to obtain the "Set-Cookie" response headers. And see the headers with "getHeaderFields" printed. Then print the cookie in fact stored in the CookieManager with "getCookieStore().getCookies()" printed.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
You will see that the expected cookies are lost in CookieManager and the following requests as I described in the part of "Description".
ACTUAL -
As I described in the part of "Description".

REPRODUCIBILITY :
This bug can be reproduced always.