tigerProxy:
+ proxyRoutes:
+ - from: /
+ to:
+ - http://orf.at/blub/
+ - http://ard.de/bla/
+diff --git a/Tiger-User-Manual.html b/Tiger-User-Manual.html index 1b97c216..3da7cdc2 100644 --- a/Tiger-User-Manual.html +++ b/Tiger-User-Manual.html @@ -165,7 +165,7 @@
Sometimes you can only at runtime know which target to use. This can be achieved by using the to
-property as a list of targets:
tigerProxy:
+ proxyRoutes:
+ - from: /
+ to:
+ - http://orf.at/blub/
+ - http://ard.de/bla/
+When booting the tiger-proxy the proxy tries to reach the target host by sending a HEAD-request to the host (dropping the path). If the server sends a valid HTTP (or HTTPS) response, the target is considered reachable and the route is used. If no target can be reached an exception is thrown. The return code is ignored.
+As an additional measure for a more fine-grained matching you can use criterions. These are JEXL-expressions which have to be fulfilled for the route to be used. This can be leveraged to make the routing decision dependent on the content of the message.
You can add optional basic-auth configuration which will be added to the forwarded message.
Theoretically this could also be done via modifications, but this a more convenient approach.
The final, easiest and most unflexible way to solve TLS-issues is to simply give a fixed server-identity.
-This identity will be used for all routes.