Thanks for the reply, but the problem is that we don't directly call CXF's cookie code. We just call ClientResponse's (it is a Jersey class) getCookies method, and the CXF method call is nested somewhere deeper.
1) ClientResponse code can be seen http://grepcode.com/file/repo1.maven.org/maven2/com.sun.jersey/jersey-bundle/1.12/com/sun/jersey/api/client/ClientResponse.java#ClientResponse.getCookies%28%29 here . This is the method we actually call. 2) NewCookie code is http://grepcode.com/file/repo1.maven.org/maven2/javax.ws.rs/jsr311-api/1.1.1/javax/ws/rs/core/NewCookie.java#NewCookie.valueOf%28java.lang.String%29 here . This is the method that #1 calls. 3) The CXF code which is finally called is http://grepcode.com/file/repo1.maven.org/maven2/org.apache.cxf/cxf-rt-frontend-jaxrs/2.5.2/org/apache/cxf/jaxrs/impl/NewCookieHeaderProvider.java#NewCookieHeaderProvider.fromString%28java.lang.String%29 here . This is the method which ultimately parses and returns the cookie from the Set-Cookie header. The method fromString in #3 has the behavior I mentioned in my first post. It considers the last name-value pair that occurs in Set-Cookie header to be the cookie itself (Eg: If the header is "Set-Cookie", "name=value; Expires=Wed, 09 Jun 2021 10:18:14 GMT", the returned cookie's name will be "expires" and value will be the date). -- View this message in context: http://cxf.547215.n5.nabble.com/Cookies-with-expires-directive-tp5649065p5651856.html Sent from the cxf-user mailing list archive at Nabble.com.
