Handling of HTTP redirects

[maestros]

I'm running a simple test case where Charon does not handle HTTP redirects as expected.

On localhost I run: 1) a Tomcat instance on 8888 running WebGoat 2) a Charon instance on 8880 that maps all requests to the Tomcat instance

There is a single mapping in the application.yml file:

  mappings:
    -
      name: webgoat
      path: /webgoat-7.0.1
      destinations: http://localhost:8888/webgoat-7.0.1
      retryable: true
      strip-path: true

3) Using the browser, I send a request to: http://localhost:8880/webgoat-7.0.1/ 4) The browser is redirected to: http://localhost:8888/webgoat-7.0.1/login.mvc

Here are the Charon logs:

2019-02-20 12:39:44.479 DEBUG 30904 --- [nio-8880-exec-4] c.g.m.charon.core.http.RequestForwarder  : Forwarding: GET /webgoat-7.0.1/ -> http://localhost:8888/webgoat-7.0.1/ 302
2019-02-20 12:39:44.479  INFO 30904 --- [nio-8880-exec-4] c.g.m.c.c.trace.LoggingTraceInterceptor  : 
  Trace ID: 9713b2be-f333-42ee-9ebb-4c4a29b540a9
  Forward HTTP response received:
    - status: 302 FOUND
    - body: null
    - headers: [Location:"http://localhost:8888/webgoat-7.0.1/login.mvc", Content-Length:"0", Date:"Wed, 20 Feb 2019 12:39:44 GMT", Content-Type:"text/html;charset=ISO-8859-1", Server:"Apache-Coyote/1.1"]
2019-02-20 12:39:44.479 DEBUG 30904 --- [nio-8880-exec-4] c.g.m.charon.core.retry.LoggingListener  : Attempt 1 to forward HTTP request using 'webgoat' mapping has succeeded

The end result is that after that point the reverse proxy is completely bypassed as the browser uses the origin server directly.

It seems to me that a reverse mapping is missing for the Location header.

I would really appreciate your thoughts here.

Many thanks, Apostolos

[mkopylec]

Indeed there is no reverse mapping for the Location header

[maestros]

Many thanks for your prompt reply @mkopylec I did a quick attempt to add a reverse mapping for the Location header but then I ended up having an infinite loop of redirections, which makes sense to me in retrospect. So, this problem seems to need a bit more careful consideration.

[mkopylec]

The cause of the was rewriting the 'Host' header to outgoing server during the request forwarding process. The outgoing server constructs the 'Location' response header using the 'Host' request header value. In 4.0.0 version 'Host' header rewriting is disabled by default.