7 Replies Latest reply on Jan 13, 2014 7:27 AM by Daniel Lechner

    Malformed jsessionid during redirect

    Daniel Lechner Novice

      I'm using Weld 1.1.16 (Final) and Mojarra 2.1.8 on JBoss-as-7.1.1.Final.


      If the user has cookies disabled in his browser, the jsessionid is part of the URL as page-parameter as expected. As an example, the URL of an h:commandLink (with an action) looks like follows: http://localhost:8080/app/page.jsf;jsessionid=FJXhUZ10JQDnMc7zk88rEfJX.undefined

      Clicking on the link results in a POST-request followed by a redirect to


      As you can see, the page-parameter jsessionid is contained twice: one ending with .jsf and the original one ending with .undefined.

      Since the first id is unknown to the server, it starts a new session showing the login-page to the user (something like http://localhost:8080/app/login.jsf;jsessionid=ooMJzeGEyzUb9TFN5aQ9-1A+.undefined).


      The code for the page itself is straightforward with only one h:commandLink defining some action embedded in an h:form.


      While debugging the problem, I found out the following:

      The redirect and the modification of the jsessionid happens in weld's ConversationPropagationFilter. During the call to sendRedirect() the FacesUrlTransformer is utilized to create the action-URL. The method toActionUrl() of the FacesUrlTransformer asks the application's viewhandler (=MultiViewHandler of jsf-impl which is wrapped by weld's ConversationAwareViewHandler).

      So when calling MultiViewHandler.getActionURL(), the passed viewId contains the jsessionid. Among other tasks, the MultiViewHandler.getActionURL() looks for the last "." in the viewId and replaces it with the registered extension (section "Deal with extension mapping" in the code). This is where .undefined gets replaced by .jsf.


      I think this is a bug in either the jsf-impl or weld. If the jsessionid must not be part of the viewId, it's weld's fault. If it may be part of it, the MultiViewHandle of JSF should handle this.