From 113ed7517756ae5af9c0ddc40393b8ea3f9df855 Mon Sep 17 00:00:00 2001 From: savagebidoof Date: Fri, 5 May 2023 01:42:27 +0200 Subject: [PATCH] 03-HTTPRewrite documented --- .../03-HTTPRewrite/README.md | 70 +------------------ 1 file changed, 1 insertion(+), 69 deletions(-) diff --git a/02-Traffic_management/03-HTTPRewrite/README.md b/02-Traffic_management/03-HTTPRewrite/README.md index edcfc2f..0be9df1 100755 --- a/02-Traffic_management/03-HTTPRewrite/README.md +++ b/02-Traffic_management/03-HTTPRewrite/README.md @@ -237,72 +237,4 @@ gateway.networking.istio.io "helloworld-gateway" deleted # Links of interest -- https://istio.io/latest/docs/reference/config/networking/virtual-service/#HTTPDirectResponse - -- https://istio.io/latest/docs/reference/config/networking/virtual-service/#HTTPBody - - - - - - - - - - - - - - - - -# There were no changes respective to that version - -Through rewriting the URI we can point to the root directory from nginx. - -```yaml - rewrite: - uri: "/" -``` - - - - - -## The idea is that this rewrite is handled "internally" by Istio, not by the Client that started the request - - -## Practical usages: - - - -If we refactor our application, and for example we previously where hosting an API to the URL `/apiV1` and now it's being hosted in `/api/V1`, we can do the following rule: - - -```yaml - - match: - - uri: - exact: /apiV1 - route: - - destination: - host: mynewapi # the service destination/target - port: - number: 80 # whatever port it is - rewrite: - uri: "/api/V1" -``` - -Or if we "upgraded" the API, and the new API (v2) is retro-compatible with the old API (v1), we could do the following to force all the usages from the old API to be handled by the newer version: - -```yaml - - match: - - uri: - exact: /api/V1 - route: - - destination: - host: mynewapi # the service destination/target - port: - number: 80 # whatever port it is - rewrite: - uri: "/api/V2" -``` +- https://istio.io/latest/docs/reference/config/networking/virtual-service/#HTTPRewrite