Page History

http.proxy.deployment.path.includes

This option defines paths allowed for HTTP proxy deployment by specifying a path prefix. Multiple paths can be specified as a comma-separated list. This ensures that only paths starting with the given segment are permitted, helping teams manage their service deployment routes and avoid conflicts by clearly identifying valid paths for each team. Proxy deployments configured with HTTP listeners are not affected.

The check is based on whether the path starts with the specified path segment. For example, if the includes property is set to /teamA, then paths like /teamA and /teamA/projects are allowed. However, paths like /teamAnother or /teamA123 will be disallowed, as they do not begin with the specified segment.

http.proxy.deployment.path.excludes

This option defines paths for HTTP proxy deployment that should be explicitly blocked by specifying exact matches. Multiple paths can be specified as a comma-separated list. This helps teams prevent certain paths from being used for their service deployments, ensuring that conflicting or unauthorized routes are excluded. Proxy deployments configured with HTTP listeners are not affected.

The path check is exact, so the specified path must match exactly. For example, if the excludes property is set to /teamA, then the path /teamA will be disallowed, but paths like /teamA/projects or /teamB will still be allowed, as they do not exactly match /teamA. By default, paths on root are disallowed.

virtual.asset.deployment.path.includes

This option defines paths allowed for virtual asset deployment by specifying a path prefix. Multiple paths can be specified as a comma-separated list. This ensures that only paths starting with the given segment are permitted, helping teams manage their service deployment routes and avoid conflicts by clearly identifying valid paths for each team.

The check is based on whether the path starts with the specified path segment. For example, if the includes property is set to /teamA, then paths like /teamA and /teamA/projects are allowed. However, paths like /teamAnother or /teamA123 will be disallowed, as they do not begin with the specified segment.

virtual.asset.deployment.path.excludes

This option defines paths for virtual asset deployment that should be explicitly blocked by specifying exact matches. Multiple paths can be specified as a comma-separated list. This helps teams prevent certain paths from being used for their service deployments, ensuring that conflicting or unauthorized routes are excluded.

The path check is exact, so the specified path must match exactly. For example, if the excludes property is set to /teamA, then the path /teamA will be disallowed, but paths like /teamA/projects or /teamB will still be allowed, as they do not exactly match /teamA. By default, paths on root are disallowed.

virtual.asset.deployment.path.enforce.unique.basepaths

This option specifies whether virtual assets are required to be deployed on unique base paths. When set to true, deploying assets on common base paths is prohibited, thus ensuring that assets cannot be deployed on paths that may be conflicting. When set to false, deploying multiple virtual assets on the same base path is allowed. Default is false.

Examples

The following scenarios illustrate how this option works when enabled:

Scenario 1: Deployment Conflict with an Exact Path

If the property is set to true and an existing asset is deployed on /api/v1/cartItems, all other assets attempting to deploy on the same path /api/v1/cartItems will be disabled.

Scenario 2: Deployment Conflict with an Ancestor Path

If the property is set to true and an existing asset is deployed on /api/v1, all other assets attempting to deploy on paths /api/v1/cartItems, /api/v1/orders, or any other paths with /api/v1 as an ancestor will be disabled. However, an asset deployed on /api/v2 will still be allowed, since /api/v1 is not an ancestor path of /api/v2.

Scenario 3: Deployment Conflict with a Descendant Path

If the property is set to true and an existing asset is deployed on /api/v1/cartItems, all other assets attempting to deploy on paths /api/v1 or /api will be disabled, as /api/v1/cartItems is a descendant of these paths. However, assets deployed on /api/v2 or /api/v1/orders will still be allowed, since /api/v1/cartItems is not a descendant of these paths.