From fe7b6ddf885790c68be0714ede9801d8db1e9abd Mon Sep 17 00:00:00 2001 From: rstoyanchev Date: Wed, 25 Oct 2023 16:17:27 +0100 Subject: [PATCH] More polishing on forwarded header scenarios See gh-31491 --- .../modules/ROOT/partials/web/forwarded-headers.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/framework-docs/modules/ROOT/partials/web/forwarded-headers.adoc b/framework-docs/modules/ROOT/partials/web/forwarded-headers.adoc index 99ccfe3c48..37cbba42d8 100644 --- a/framework-docs/modules/ROOT/partials/web/forwarded-headers.adoc +++ b/framework-docs/modules/ROOT/partials/web/forwarded-headers.adoc @@ -95,10 +95,10 @@ have the empty prefix override server prefixes `/app1` and `/app2`. ==== A common case for this deployment scenario is where licenses are paid per production application server, and it is preferable to deploy multiple applications per -server to reduce fees. Another case is I/O bound applications, and the need to deploy -multiple applications to each application server to consume less resources. +server to reduce fees. Another reason is to run more applications on the same server in +order to share the resources required by the server to run. -In this scenario, applications need a non-empty context root because there are multiple +In these scenarios, applications need a non-empty context root because there are multiple applications on the same server. However, this should not be visible in URL paths of the public API where applications may use different subdomains that provides benefits such as: