2 Replies Latest reply on Sep 21, 2018 7:06 AM by Stefan Oberwahrenbrock

    Session cookies generated by WildFly 13.0 backend servers causing trouble at Apache load balancer

    Stefan Oberwahrenbrock Newbie

      Hello fellow WildFly users!

       

      Upgrading from WildFly 10.1 to 13.0 I stumbeled over an issue, I 'd like to mention here. Obviously the behaviour on creating session cookies now depends on wether you 're using WildFly in standalone mode or domain mode.

       

      With the Firefox plugin "HTTP header live" I observied different set-cookie directives in these two modes.

       

      In standalone mode it looks like this:

      Set-Cookie: JSESSIONID=1b51he-PLdFyMh_u6gXa1nxioiWeEVhpZ0P7WFkb.jessie64; path=/myapp

       

      In domain mode it looks like this:

      Set-Cookie: JSESSIONID="V2RZyDaCXdTV5GS5DdRjqiBQNXtYGwYwajVcEkIO.node01:server-one"; Version=1; Path=/myapp

       

      The quotation marks surrounding the session id caused some trouble at the Apache load balancer (mod_proxy_balancer), which was not able to handle requests to the WildFly backend servers "sticky" any more. Before the upgrade of WildFly we had a working Apache configuration, which basically looked like this:

      <Proxy balancer://myapp-balancer-http>

         BalancerMember http://node01.example.com:8230 route=node01:server-one timeout=3600

         BalancerMember http://node02.example.com:8230 route=node02:server-one timeout=3600

         ProxySet lbmethod=byrequests stickysession=JSESSIONID|jsessionid scolonpathdelim=On

      </Proxy>

       

      After the upgrade to WildFly 13.0 we had to adjust this configuration to consider the additional quotation mark. The new configuration basically looks like this now:

      <Proxy balancer://myapp-balancer-http>

         BalancerMember http://node01.example.com:8230 route=node01:server-one" timeout=3600

         BalancerMember http://node02.example.com:8230 route=node02:server-one" timeout=3600

         ProxySet lbmethod=byrequests stickysession=JSESSIONID|jsessionid scolonpathdelim=On

      </Proxy>

       

      Following the Apache documentation this seems comprehensible in a way as the text contains the following information:

      Some back-ends use a slightly different form of stickyness cookie, for instance Apache Tomcat. Tomcat adds the name of the Tomcat instance to the end of its session id cookie, separated with a dot (.) from the session id. Thus if the Apache web server finds a dot in the value of the stickyness cookie, it only uses the part behind the dot to search for the route. [...] The name of the session cookie used by Tomcat (and more generally by Java web applications based on servlets) is JSESSIONID (upper case) but can be configured to something else.

       

      I have to admit, that the updated Apache configuration looks a little bit strange to me. Thus, I am interessted in your opinion/epertise:

      • Do you consider the different behaviour on creating session cookies in standalone mode and domain mode a bug in WildFly one should report?
      • Does anybody know a possible configuration option to restore the old behaviour or make it equal in both modes?

       

      Thanks and greetings,

      Stefan Oberwahrenbrock

        • 1. Re: Session cookies generated by WildFly 13.0 backend servers causing trouble at Apache load balancer
          Paul Ferraro Master

          This is not a difference between standalone vs domain mode, but rather a difference between WF10 vs WF13.  WF11 added support for legacy cookie behavior to improve compatibility with cookies generated by JBoss Web (Undertow's predecessor).

          See:

          [UNDERTOW-1096] Add correct quoting to the cookie for a backward compatible behavior to EAP 6 (JBossWeb) - JBoss Issue T…

          [WFLY-9810] Enable setting of default cookie version in Undertow - JBoss Issue Tracker

           

          You can force the cookie version using the new default-cookie-version servlet-container attribute added to the Undertow subsystem per WFLY-9810.

          wildfly/wildfly-undertow_6_0.xsd at 13.0.0.Final · wildfly/wildfly · GitHub

           

          However, it looks like the version of mod_proxy_balancer you are using does not correctly parse quoted cookie values, which is permitted by older versions of the spec:

          https://www.w3.org/Protocols/rfc2109/rfc2109

          https://www.ietf.org/rfc/rfc2965.txt

          • 2. Re: Session cookies generated by WildFly 13.0 backend servers causing trouble at Apache load balancer
            Stefan Oberwahrenbrock Newbie

            Paul, thank you for the details and additional resources you referenced by links!

             

            Your input made me think, that I can change the behaviour of the cookie creation by setting the additional attribute default-cookie-version="0" for the servlet-container. Unfortunately I do not see any changes in bahaviour by setting the attribute to "0" or "1" - neither in standalone mode nor in domain mode. And still both modes generate different session cookies.

             

            My standalone config is based on default "standalone-ha.xml" and in my "domain.xml" I am using profile "ha". In both configs the relevant undertow part looks identical. I include it here and mark the additional settings I made in green (they work) and the new setting concerning the cookie in red (does not seem to work).

             

            Maybe someone can give a hint, what I might haven overseen?

             

            <subsystem xmlns="urn:jboss:domain:undertow:6.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other">

                <buffer-cache name="default"/>

                <server name="default-server">

                    <ajp-listener name="ajp" socket-binding="ajp"/>

                    <http-listener name="default" socket-binding="http" max-parameters="10000" redirect-socket="https" proxy-address-forwarding="true" enable-http2="true"/>

                    <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>

                    <host name="default-host" alias="localhost">

                        <location name="/" handler="welcome-content"/>

                        <filter-ref name="server-header"/>

                        <filter-ref name="x-powered-by-header"/>

                        <filter-ref name="gzipFilter" predicate="exists('%{o,Content-Type}') and regex(pattern='(?:application/javascript|text/css|text/html|text/xml|application/json)(;.*)?', value=%{o,Content-Type}, full-match=true)"/>

                        <filter-ref name="Vary-header"/>

                        <http-invoker security-realm="ApplicationRealm"/>

                    </host>

                </server>

                <servlet-container name="default" default-cookie-version="0">

                    <jsp-config/>

                    <websockets/>

                </servlet-container>

                <handlers>

                    <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>

                </handlers>

                <filters>

                    <response-header name="server-header" header-name="Server" header-value="WildFly/13"/>

                    <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/2"/>

                    <response-header name="Vary-header" header-name="Vary" header-value="Accept-Encoding"/>

                    <gzip name="gzipFilter"/>

                </filters>

            </subsystem>