Question

Folks,

Used to be that when you hit a servlet/jsp, the app server would automatically start a session. It would put a session cookie in the first dynamic response that would get tracked throughout.

I have a rest backend and I notice that no session cookies are being traded. So I manually add code to send the JSESSIONID cookie:

@Context 
private HttpServletRequest httpRequest;
// ...
@GET
@Path( "/{rcpGuid}" )
public Response myMethod( ... )
{
    final HttpSession session = httpRequest.getSession();
    final String sSessionId = session.getId();
    ...
    return Response.status( Response.Status.SEE_OTHER ).
        location( redirectUrl ).cookie( new NewCookie( "JSESSIONID", sSessionId ) );
}

Now this is causing 2 copies of the JSESSIONID cookie being returned where before there was no Set-Cookie header. This is what I see now in my browser’s inspector:

Set-Cookie:JSESSIONID=sdm-Q1P6pRoQbKd4-9cJylGb; Path=/nn, JSESSIONID=sdm-Q1P6pRoQbKd4-9cJylGb; Version=1

I don’t care as long as this would work. But unfortunately, when my browser requests the URL being redirected to (notice that the response is “SEE_OTHER”), that request does not bear the session id. This causing my app to not function right.

Any insights?

Answer 1

Used to be that when you hit a servlet/jsp, the app server would automatically start a session. It would put a session cookie in the first dynamic response that would get tracked throughout.

The app server doesn’t create a session until httpRequest.getSession() is called.

I have a rest backend and I notice that no session cookies are being traded. So I manually add code to send the JSESSIONID cookie:

In your example, you call getSession() and create a separate jsessionid cookie. That would explain why you have two cookies. If you do neither, you wont have a jessionid at all.