Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-17925

[GSS](7.3.z) UNDERTOW-1599 - access-log does not output the original query string after the servlet request is forwarded with new query strings

XMLWordPrintable

    • Resolved in Undertow 2.0.27.Final
    • Workaround Exists
    • Hide

      Create custom AccessLogHandlerBuilder and custom ServletRequestLineAttribute like the attached undertow-custom-accesslog-exchangeattribute.zip. Deploy it as a custom module and specify "custom-access-log" in the expression filter. See README.md in the undertow-custom-accesslog-exchangeattribute.zip for details.

      Show
      Create custom AccessLogHandlerBuilder and custom ServletRequestLineAttribute like the attached undertow-custom-accesslog-exchangeattribute.zip. Deploy it as a custom module and specify "custom-access-log" in the expression filter. See README.md in the undertow-custom-accesslog-exchangeattribute.zip for details.
    • Hide

      1. Enable <access-log> setting in undertow subsystem

              <subsystem xmlns="urn:jboss:domain:undertow:7.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">
                ...
                <host name="default-host" alias="localhost">
                    <location name="/" handler="welcome-content"/>
                    <http-invoker security-realm="ApplicationRealm"/>
                    <access-log/> <!-- add this -->
                </host>
            </server>
            ...
        </subsystem>

      2. Deploy the attached example.war
      3. Send the following request:

      $curl -v http://localhost:8080/example/?aaa=bbb

      4. Check the access-log.log. It does not log the original query string (?aaa=bbb) but log the new query string (?foo=bar) of the forwarded request:

      127.0.0.1 - - [10/Oct/2019:20:20:54 +0900] "GET /example/?foo=bar HTTP/1.1" 200 68
      Show
      1. Enable <access-log> setting in undertow subsystem <subsystem xmlns= "urn:jboss:domain:undertow:7.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" > ... <host name= " default -host" alias= "localhost" > <location name= "/" handler= "welcome-content" /> <http-invoker security-realm= "ApplicationRealm" /> <access-log/> <!-- add this --> </host> </server> ... </subsystem> 2. Deploy the attached example.war 3. Send the following request: $curl -v http: //localhost:8080/example/?aaa=bbb 4. Check the access-log.log. It does not log the original query string (?aaa=bbb) but log the new query string (?foo=bar) of the forwarded request: 127.0.0.1 - - [10/Oct/2019:20:20:54 +0900] "GET /example/?foo=bar HTTP/1.1" 200 68

      When a servlet request is forward to a different path with a new query string, ServletRequestLineAttribute (%r) does not output a query string of the original request in the access log.

      For example, when the following dispatcher.forward() is implemented in the application:

      RequestDispatcher dispatcher = request.getRequestDispatcher("/test?foo=bar");
dispatcher.forward(request, response);

      and the following request is sent to the above code:

      $ curl -v http://localhost:8080/example/?aaa=bbb

      The access-log should output the original query string (?aaa=bbb), but it output the new query string (?foo=bar) of the forwarded request:

      127.0.0.1 - - [10/Oct/2019:20:20:54 +0900] "GET /example/?foo=bar HTTP/1.1" 200 68

        1. example.war
          1 kB
        2. undertow-custom-accesslog-exchangeattribute.zip
          10 kB

              flaviarnn Flavia Rainone
              rpelisse@redhat.com Romain Pelisse
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: