ai-proxy: bedrock provider does not detect /anthropic/v1/messages under protocol: original - request mis-routed to wrong AWS endpoint and auth

Summary

With protocol: original, the bedrock provider does not recognize its own Anthropic messages endpoint (/anthropic/v1/messages). The request resolves to an empty apiName and is treated as an unsupported path, which both skips the dedicated Anthropic pipeline and mis-routes the request to the wrong AWS endpoint with the wrong authentication.

Environment

• Higress commit: b44d4f77011ad7f63c2fefef5b8cd2dec0cff1c6 (current main, 2026-09-28)
• Plugin: ai-proxy (wasm-go), provider bedrock

Configuration

apiVersion: extensions.higress.io/v1alpha1
kind: WasmPlugin
metadata:
  name: ai-proxy-bedrock-original
spec:
  defaultConfig:
    provider:
      awsRegion: us-east-1
      apiTokens: ["<token>"]
      protocol: original
      type: bedrock

Steps to reproduce

curl -X POST http://<gateway>/anthropic/v1/messages \
  -H "Content-Type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model":"anthropic.claude-3-5-sonnet-20240620-v1:0","max_tokens":64,"messages":[{"role":"user","content":"hi"}]}'

Actual behavior (observed on a live gateway)

wasm log <plugin>: [ai-proxy] [onHttpRequestHeader] provider=bedrock
wasm log <plugin>: [ai-proxy] [onHttpRequestHeader] unsupported path: /anthropic/v1/messages, will not process http path and body

Two consequences:

1. The request/response bodies are never processed — onAnthropicMessagesRequestBody (bedrock.go:776) and the dedicated response handling (bedrock.go:798, bedrock.go:1687) are skipped.
2. TransformRequestHeaders still runs with the empty apiName and takes the default branch (bedrock.go:744): the request host is rewritten to the default Bedrock invoke domain and Bearer/SigV4 auth is applied — instead of the mantle domain, anthropic-version header and x-api-key auth that the ApiNameAnthropicMessages branch applies (bedrock.go:732-741). Against real AWS the request therefore reaches the wrong endpoint with the wrong authentication.

A control request to the native converse path (/model/<model-id>/converse) is processed normally, so the issue is specific to the mantle messages path.

Why this is a defect

bedrockProviderInitializer.DefaultCapabilities() declares ApiNameAnthropicMessages -> /anthropic/v1/messages (bedrock.go:83), but GetApiName() only matches the converse/invoke patterns (bedrock.go:715-724) — the provider advertises a capability that its own path resolver cannot detect. This is the same defect class as #4836/#4837/#4838/#4839 (fixed in #4219/#4220/#4217/#4218).

Observed with the fix

GetApiName additionally classifies the mantle messages path as ApiNameAnthropicMessages (validated on the same live gateway):

wasm log <plugin>: [ai-proxy] [onHttpRequestHeader] provider=bedrock
wasm log <plugin>: [ai-proxy] [onHttpRequestBody] provider=bedrock
wasm log <plugin>: [ai-proxy] [onHttpRequestBody] newBody={"model":"anthropic.claude-3-5-sonnet-20240620-v1:0",...}

No unsupported path warning; the request is routed through the anthropic-messages pipeline (mantle domain, anthropic-version, x-api-key, dedicated body/response handling).