Replies: 1 comment
-
Proposal 2Introduce a This scheme is extensible when we introduce operational level endpoints in the future. apiVersion: gateway.api-platform.wso2.com/v1alpha1
kind: RestApi
metadata:
name: weather-api-v1.0
spec:
displayName: Weather-API
version: v1.0
context: /weather/$version
upstream:
main:
url: http://sample-backend:5000/api/v2
hostRewrite: manual
operations:
- method: GET
path: /{country_code}/{city}
- method: GET
path: /alerts/active |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Overview
An LLM proxy consumes an admin-created LLM provider through Envoy using loopback. When an LLM provider is deployed without a VHost configuration, the LLM proxy can access it via the internal loopback IP (
127.0.0.1).However, when the provider is deployed with a VHost configuration, one of the following is required:
Hostheader, or/etc/hosts.With the current implementation, all listeners are configured with
auto_host_rewriteenabled [1][2]. As a result, Envoy replaces the incomingHostheader with the hostname of the upstream selected by the cluster manager. This behavior prevents correct routing to VHost-based providers.To address this, a configuration option in
api.yamlis required to disable host rewrite either at the API level or at the operation level.API Level
Operational Level
[1] -
api-platform/gateway/gateway-controller/pkg/xds/translator.go
Line 836 in bb8a758
[2] - https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto
Beta Was this translation helpful? Give feedback.
All reactions