Undertow (JBoss 7) mangles / re-encodes URL-encoded parameter on redirect

Question

Posted in JBoss forums as well: https://developer.jboss.org/thread/280195

update 2019-06-26 apparently this is now confirmed as a bug in Undertow, with a pull request submitted here.

This is a SSCCE.

I have a very simple Servlet that does nothing except print the value of a parameter:

public class TestServlet extends HttpServlet{
    public void service(HttpServletRequest req, HttpServletResponse res)
    throws ServletException, IOException {
        final String URL = req.getParameter("url");
        System.out.printf("url parameter read as: [%s]
", URL);
    }
}

My application's web.xml is configured so as to automatically redirect http access to https:


 ...

    
        SECURE
        /*
    
    
        CONFIDENTIAL

… and I also have (in my standalone-full.xml configuration file) the redirect-socket attribute set in the definition of the http-listener:

If I deploy to JBoss EAP 7.1 and enter the following URL in my browser (where the url parameter carries the URL-encoded value of "http://www.google.com"):

http://localhost:8082/get-parameter-test/min?url=http%3A%2F%2Fwww.google.com

… this is what I see in the developer console:

As a result, after the automatic redirect, my code fails to obtain the correct value of the url parameter and I see in the log files:

url parameter read as: [http%3A%2F%2Fwww.google.com]

However, if I deploy to JBoss EAP 6.2 and do the same, the URL is not mangled in the redirect and everything works fine:

update

this answer suggests that the decode-url parameter in the configuration of the http-listener and https-listener in the undertow system in the JBoss configuration file (standalong-full.xml) may have something to do with this. This is wrong. I tried all four combinations:

http-listener: decode-url="false" and https-listener: decode-url="false"
http-listener: decode-url="false" and https-listener: decode-url="true"
http-listener: decode-url="true" and https-listener: decode-url="false"
http-listener: decode-url="true" and https-listener: decode-url="true"

In all cases, the 302 response that's effecting the redirect from http to https has the following header:

Location: https://localhost:8445/get-parameter-test?url=http%253A%252F%252Fwww.google.com

That is in all cases, the URL is mangled (call it re-encoded it if you like, it's mangled AFAIAC). There's no reason for this behavior at all and it is not what EAP 6.2 does. The value of the decode-url parameter only affects the behavior of the HttpServletRequest#getRequest method inside your servlet, it has no effect whatsoever in the redirected URL.

Marcus Junius Brutus · Accepted Answer

update 2019-06-26 Apparently this is now confirmed as a bug in Undertow, with a pull request submitted here

Here's what ultimately worked for me. First of all, I removed from my web.xml the entire element as it is not needed for the solution I implemented. I also removed the redirect-socket="https" from the configuration. That too, is also not needed. So here's what my and look like:

I think the above is exactly what you get in JBoss EAP 7.1 out of the box, so no need to change that.

I then created a filter and added it in the element of the undertow subsystem:

%h is the remote host name
%U is the requested URL path
%q is the query string (automatically prepended with ? if it exists)

I found the above codes here - I am sure there's a more normative reference somewhere else but they seem to work.

Finally, I added a reference to the filter, along with a predicate, in the / element (also in the undertow subsystem):

With the above configuration the request gets redirected without re-encoding the URL:

$ curl -I -L -k http://localhost:8082/get-parameter-test?url=http%3A%2F%2Fwww.google.com
HTTP/1.1 302 Found
Connection: keep-alive
Server: JBoss-EAP/7
Location: https://127.0.0.1:8445/get-parameter-test?url=http%3A%2F%2Fwww.google.com
Content-Length: 0
Date: Tue, 11 Jun 2019 17:43:23 GMT

HTTP/1.1 200 OK
Connection: keep-alive
X-Powered-By: Undertow/1
Server: JBoss-EAP/7
Content-Length: 0
Date: Tue, 11 Jun 2019 17:43:23 GMT

… and the parameter is correctly read from Java:

url parameter read as: [http://www.google.com]

There is no need to set decode-url="true" in the http/https listeners as that's the default value.

NB: The above causes JBoss EAP 7.1 to send a 302 redirect. I have no idea how to configure a 303 or 307 redirect.

Final remark

The obvious alternative to the above is to do the redirect programmatically from your application's code using HttpServletRequest#sendRedirect. In that case too, you do not need redirect-socket="https" in your http-listener.

Apparently, the redirect-socket attribute is only necessary in conjunction with the element in your application's web.xml. That's because otherwise (i.e. if you have the in your web.xml but no redirect-socket in your http-listener), you get hit with:

ERROR [io.undertow.request] (default task-14) UT005001: An exception occurred processing the request: java.lang.IllegalStateException: UT010053: No confidential port is available to redirect the current request.).

However if you have both the and the redirect-socket, the query String is needlessly re-URL-encoded (and thus mangled) in the redirected URL as explained in the question. So it's not clear to me what's the use of in JBoss EAP 7.1.

Undertow (JBoss 7) mangles / re-encodes URL-encoded parameter on redirect

update

Answers (2)

Final remark

Related Questions