Istio默认不识别XML上传流量，需通过EnvoyFilter配置buffer和Lua filter实现大小限制与Content-Type拦截，并用WASM或Header方式实现基于XML的路由及动态指标打标。
XML上传流量在Istio中默认不被特殊识别
Istio本身不解析HTTP body内容，因此application/xml或text/xml上传请求（比如POST /upload带XML payload）在Envoy层面只是普通HTTP流量——不会自动做schema校验、大小限制或路由分流。你得靠显式配置来干预。
常见误判是以为启用了Sidecar就能“自动管理XML”，其实它只管七层路由、TLS、mTLS、指标采集这些基础能力，body内容得自己加规则。
用EnvoyFilter对XML上传做大小限制和Content-Type拦截
如果你要防恶意大XML（如XXE或DoS），不能只靠应用层，得在入口网关（Gateway）或Sidecar的HTTP filter链里插一层校验。Istio 1.17+推荐用EnvoyFilter注入envoy.filters.http.buffer + 自定义envoy.filters.http.lua逻辑。
-
bufferfilter可设max_request_bytes，比如限制所有Content-Type: application/xml请求不超过2MB - Lua filter可读
headers[":content-type"]和headers["content-length"]，匹配成功后直接respond(413, "XML too large") - 注意：Lua脚本不能解析XML结构，只能做头部+长度判断；真要校验XML格式，得让后端服务处理或用WASM扩展
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: xml-upload-limit
namespace: istio-system
spec:
configPatches:
- applyTo: HTTP_FILTER
match:
context: GATEWAY
listener:
filterChain:
filter:
name: "envoy.filters.network.http_connection_manager"
subFilter:
name: "envoy.filters.http.router"
patch:
operation: INSERT_BEFORE
value:
name: envoy.filters.http.buffer
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.buffer.v3.Buffer
max_request_bytes: 2097152 # 2MB
- applyTo: HTTP_FILTER
match:
context: GATEWAY
listener:
filterChain:
filter:
name: "envoy.filters.network.http_connection_manager"
subFilter:
name: "envoy.filters.http.buffer"
patch:
operation: INSERT_AFTER
value:
name: envoy.filters.http.lua
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua
inlineCode: |
function envoy_on_request(request_handle)
local ct = request_handle:headers():get("content-type")
local cl = request_handle:headers():get("content-length")
if ct and string.find(ct, "application/xml") and cl and tonumber(cl) > 2097152 then
request_handle:respond({[":status"] = "413"}, "XML payload exceeds 2MB")
end
end
按XML命名空间或根元素做路由需要WASM或自定义filter
Istio原生VirtualService不支持基于XML body内容路由（比如<order xmlns="https://acme.com/v1"></order> → v1服务，<order xmlns="https://acme.com/v2"></order> → v2服务）。Envoy的http_route只支持header/path/method匹配。
- 可行路径一：用
proxy-wasm写一个轻量filter，在on_http_request_headers阶段延迟读body（需开启stream_idle_timeout避免超时），解析前几KB找<root>或<code>xmlns，再动态改:authority或添加x-route-toheader供后续VirtualService使用 - 可行路径二：让客户端在header里带
X-XML-Schema-Version: v2，然后用VirtualService的match.headers路由——这是最简单且符合Istio设计边界的方案 - 别踩坑：别在Lua里调
request_handle:body()，它会阻塞整个worker线程，高并发下直接拖垮Envoy
监控XML上传失败的关键指标要自己补label
Istio默认的istio_requests_total指标不区分XML和其他content-type，你查不到“XML 413错误有多少”。必须用EnvoyFilter或Telemetry API给metric打标：
- 在Lua filter里用
request_handle:streamInfo():dynamicMetadata():set("envoy.filters.http.lua", "xml_upload", "true") - 再配
Telemetry资源，把dynamic_metadata["envoy.filters.http.lua"]["xml_upload"]作为reporting_duration的label之一 - Prometheus查询就变成：
sum(rate(istio_requests_total{xml_upload="true", response_code=~"4.."}[1h])) by (response_code)
没这步，出了问题只能翻access log grep "application/xml"，没法聚合分析。
