Sorry, here is the change I made if additional or cookies already contains
the name then just return...
io.undertow.util.Cookies:
private static int createCookie(final String name, final String value,
int maxCookies, int cookieCount,
final Map<String, String> cookies, final Map<String, String>
additional) {
if (name.charAt(0) == '$') {
//added
if(additional.containsKey(name)) {
return cookieCount;
}
additional.put(name, value);
return cookieCount;
} else {
if (cookieCount == maxCookies) {
throw UndertowMessages.MESSAGES.tooManyCookies(maxCookies);
}
//added
if(cookies.containsKey(name)) {
return cookieCount;
}
cookies.put(name, value);
return ++cookieCount;
}
}
On Fri, Apr 25, 2014 at 2:43 PM, Derrick Childers <
derrick.childers(a)gmail.com> wrote:
I think I've found a bug in undertow and I have patch. I thought
I'd
explain. We have multiple War's serving a site. One war covers the root
context '/' and a variety of sub paths/contexts. A couple of other war's
server specific sub contexts, such as /selfserve. If you open a browser
and go to / and look at the browser cookies you will see JSESSIONID with
path=/. Then go to /selfserve and look at the cookies. You now have two
JSESSIONID cookies. One for path=/ and one for path=/selfserve. As far as
I know this is all normal and correct. From here when my app tries to use
the session it fails in various ways. What I found was that if I deleted
the JSESSIONID cookie that was associated with path=/ then everything
worked. After digging around in the code I found where the cookies are
being added to a HashMap by the name. It looks like the last cookie loaded
wins, which means the correct cookie is loaded first then overridden by the
wrong one.
I have a patch in git and can send a pull request.
--
Derrick Childers
--
Derrick Childers