title: Unable to Remove ;jsessionid in a Spring Boot / Web Flow Application's URL when Deployed to Tomcat 8.5
body: <p>I'm working on a Java application where a user registers a password for his/her account. The following are being used:</p>
  <ul>
  <li>Spring Boot</li>
  <li>Spring MVC</li>
  <li>Spring Web Flow</li>
  <li>Spring Security</li>
  <li>Thymeleaf</li>
  <li>Interceptor (for checking the session in the <code>preHandle</code> method)</li>
  </ul>
  <hr />
  <p>For the Spring Security part, there's really no authentication required. I just use it to handle CSRF and the configuration is as follows:</p>
  <pre class="lang-java prettyprint-override"><code>@Configuration
  @EnableWebSecurity
  @EnableGlobalMethodSecurity(securedEnabled = true, prePostEnabled = true)
  public class SecurityConfig extends WebSecurityConfigurerAdapter {
  
     @Override
     protected void configure(HttpSecurity http) throws Exception {
        // CSRF feature only
        http.authorizeRequests().anyRequest().permitAll();
     }
  
  }
  </code></pre>
  <hr />
  <p>Now, this is where things get messy. When I deploy it to Tomcat in a Unix environment, <code>;jsessionid</code> gets appended to the URL and Spring Security is not happy. I have scrounged the Internet and found the following solutions to remove it (alongside my results).</p>
  <hr />
  <p><code>server.servlet.session.tracking-modes=cookie</code> in <strong><code>application.properties</code></strong> does nothing.</p>
  <hr />
  <p><strong><code>web.xml</code></strong></p>
  <pre class="lang-xml prettyprint-override"><code>&lt;session-config&gt; 
     &lt;tracking-mode&gt;COOKIE&lt;/tracking-mode&gt; 
  &lt;/session-config&gt;
  </code></pre>
  <p><strong>or</strong></p>
  <pre class="lang-java prettyprint-override"><code>@Configuration
  public class WebConfig implements WebApplicationInitializer {
  
     @Override
     public void onStartup(ServletContext servletContext) {
        HashSet&lt;SessionTrackingMode&gt; set = new HashSet&lt;&gt;();
        set.add(SessionTrackingMode.COOKIE);
        servletContext.setSessionTrackingModes(set);
     }
  
  }
  </code></pre>
  <p>yields an <code>IllegalArgumentException: The session tracking mode [COOKIE] requested for context [/&lt;context-name&gt;] is not supported by that context</code></p>
  <hr />
  <p>I'm about to pull what remains of my hair off so I reverted any <code>cookie</code>-related changes and thought of just allowing semicolons in the URL (I know, I know, not secure) using the snippet below in the same <code>SecurityConfig</code> class.</p>
  <pre class="lang-java prettyprint-override"><code>   @Bean
     public HttpFirewall allowUrlSemicolonHttpFirewall() {
        StrictHttpFirewall firewall = new StrictHttpFirewall();
        firewall.setAllowSemicolon(true);
        return firewall;
     }
  
     @Override
     public void configure(WebSecurity web) throws Exception {
        super.configure(web);
        web.httpFirewall(allowUrlSemicolonHttpFirewall());
     }
  </code></pre>
  <p>And voila! The web flow runs on an infinite redirect.</p>
  <hr />
  <p><strong>Questions:</strong></p>
  <ul>
  <li>Has anyone ever encountered <code>IllegalArgumentException: The session tracking mode [COOKIE] requested for context [/&lt;context-name&gt;] is not supported by that context</code> before? I've searched far and wide and the closest that I could find is <a href="https://github.com/spring-projects/spring-boot/issues/12058" rel="nofollow noreferrer">this</a>.</li>
  <li>Could the reason behind <code>server.servlet.session.tracking-modes=cookie</code> not working be the same as above?</li>
  <li>Could the infinite redirect be caused by <code>http.authorizeRequests().anyRequest().permitAll()</code>? I tried using <code>anonymous()</code> but the result was the same.</li>
  <li>Is it possible to know which part exactly is causing the infinite redirect?</li>
  </ul>
  <hr />
  <p>Please note that allowing semicolons in the URL is working fine and dandy in my <code>localhost</code>, so I have a hunch that what's causing the redirects is SSL-related. In the same way that locally <code>;jsessionid</code> is not being appended to the URL.</p>
  <p>My next step is to try configuring SSL locally in an attempt to replicate the issue. In the meantime, any help would be highly appreciated. My apologies if there's too much information here; I'm willing to repost it as multiple questions if that's necessary.</p>