Mule-ESB HTTP redirect does not work when followRedirects=false - mule

Question

I have a simple flow that didn’t work for mule. In my setup, I am listening on one port for HTTP traffic and forwarding traffic on another port which I believe is the most typical ESB use case. The proxy/gateway flow works except when the target application issues redirect. Does anyone know of any tricks to address this? Note that I can not use the "HTTP-Proxy pattern" from mule as I intend to extend this flow for more complex use case.
Mule Flow
<http:listener-config name=“HTTP_IN" host=“localhost" port="12344" doc:name=“IN_EP" />
<http:request-config name=“HTTP_OUT" host=“localhost" port="8380" doc:name=“OUT_EP"/>
<flow name="test2Flow2">
<http:listener config-ref=“HTTP_IN" path="*" doc:name="IN"/>
<logger level="INFO" doc:name="Request Logger"/>
<http:request config-ref=“HTTP_OUT" path="#[message.inboundProperties.'http.request.path']" method="#[message.inboundProperties.'http.method']" doc:name="OUT" followRedirects="false" />
<response>
<logger level="INFO" doc:name="Response Logger"/>
</response>
</flow>
Case 1: followRedirects=true (default)
In this case mule gets HTTP 302 from target end point and it internally navigates to the redirected page and serves the page to the client. This is great if I am using Mule as a gateway to some web services. However for HTTP traffic from browser, if we allow this to happen, all the relative URLs will break from the rendered page.
Case 2: followRedirects=false
In this case mule gets HTTP 302 from target end point and it drops the response after logging it. Mule just send HTTP 200 on the browser with empty HTML page. See logs below for case 2. I like to send the HTTP 302 response to the end-user.
Request Logged (Case 2)
INFO 2015-10-01 13:01:48,333 [[test2].APP_A_IN.worker.01] org.mule.api.processor.LoggerMessageProcessor:
org.mule.DefaultMuleMessage
{
Message properties:
INVOCATION scoped properties:
INBOUND scoped properties:
accept=text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
accept-encoding=gzip, deflate, sdch
accept-language=en-US,en;q=0.8
cache-control=max-age=0
connection=keep-alive
dnt=1
host=localhost:12344
http.listener.path=/*
http.method=GET
http.query.params=ParameterMap{[]}
http.query.string=
http.relative.path=/app_a
http.remote.address=/127.0.0.1:53372
http.request.path=/app_a
http.request.uri=/app_a
http.scheme=http
http.uri.params=ParameterMap{[]}
http.version=HTTP/1.1
upgrade-insecure-requests=1
user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
x-firephp-version=0.0.6
OUTBOUND scoped properties:
SESSION scoped properties:
}
Response Logged (Case 2)
INFO 2015-10-01 13:01:48,420 [[test2].APP_A_IN.worker.01] org.mule.api.processor.LoggerMessageProcessor:
org.mule.DefaultMuleMessage
{
Message properties:
INVOCATION scoped properties:
INBOUND scoped properties:
date=Thu, 01 Oct 2015 17:01:48 GMT
http.reason=Moved Temporarily
http.status=302
location=http://localhost:8380/app_a/
server=Apache-Coyote/1.1
transfer-encoding=chunked
OUTBOUND scoped properties:
SESSION scoped properties:
}

Answer 1

I think the problem is that you are not copying the properties from the requester to the listener's response. I suggest using a copy-properties element right after the requester. The inbound properties will be lost otherwise: you need them as outbound at that point.
Some properties like the http.status might need to be mapped to headers explicitly using a response-builder though.
HTH