janiussyafiq opened a new pull request, #13915: URL: https://github.com/apache/apisix/pull/13915
### Description #### Motivation Follow-up to #13909, addressing https://github.com/apache/apisix/pull/13909#issuecomment-5520928764. `ctx.var` caches a variable on its first read. The header filter added in #13909 sets `ngx.var.request_type` directly, so a plugin that already resolved `$request_type` before the `101` upgrade completes leaves the cached value at `traditional_http`. A supported trigger is a WebSocket route whose `proxy-rewrite` sets a header to `$request_type`. The prometheus exporter reads `ctx.var` in the log phase, so `apisix_http_status`, `apisix_http_latency` and `apisix_bandwidth` label the whole session as ordinary HTTP and `request_type!="websocket"` no longer excludes it. #### What this PR does - Writes `request_type = "websocket"` through `api_ctx.var`, whose setter updates both the NGINX variable and the cached view, keeping the bare `ngx.var` write as the fallback when no request context exists. - Adds a regression to `t/plugin/prometheus-websocket.t`: a route whose `proxy-rewrite` sets `X-Request-Type: $request_type` reads the variable before the upgrade. The log phase asserts that the upstream header carried `traditional_http` (the early read happened) and that `ngx.var` and `ctx.var` both report `websocket`, and the three metric families are checked for that route. No behaviour change for requests that never read `$request_type` before the upgrade. #### Which issue(s) this PR fixes: Fixes # ### Checklist - [x] I have explained the need for this PR and the problem it solves - [x] I have explained the changes or the new features added to this PR - [x] I have added tests corresponding to this change - [ ] I have updated the documentation to reflect this change - [x] I have verified that this change is backward compatible (If not, please discuss on the [APISIX mailing list](https://github.com/apache/apisix/tree/master#community) first) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
