0
votes

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:
}
1

1 Answers

0
votes

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