nic-6443 commented on PR #13680: URL: https://github.com/apache/apisix/pull/13680#issuecomment-4957138840
One more data point on the patch.lua idea: `core/json.lua` sets a second option, `encode_escape_forward_slash(false)` (#8684), and it turns out that one is sitting on a semantic boundary in lua-cjson right now. In the lua-cjson bundled by apisix-runtime (2.1.0.11), that setter mutates a **shared static escape table**, not per-instance config. I verified it: calling it on the `cjson.safe` singleton flips the behavior of previously-created private instances and of the plain `cjson` module too. So today `core/json.lua` already covers every dependency's private instance process-wide — by accident. But upstream changed this on 2026-06-14 (openresty/lua-cjson: "setting encode_escape_forward_slash on a cjson instance does not affect other instances" — `char2escape` moved into the per-config struct). The moment a future runtime upgrade picks that up, every private cjson instance in our deps silently reverts to escaping `/` as `\/`. That's a byte-level output change riding along a runtime bump, which matters anywhere serialized JSON gets signed or string-compared. So the patch.lua wrapper should set both options. For `encode_escape_forward_slash(false)` it isn't even a behavior change — it just pins today's actual process-wide behavior so it survives the upstream semantic change. It also aligns with basically every mainstream serializer: JS, Python, Go, Ruby, Java (Jackson/Gson), Rust, .NET all leave `/` unescaped; PHP is the lone holdout that escapes by default. Escaping `/` is a leftover from the embed-JSON-in-`<script>` era, and RFC 8259 treats both forms as equivalent anyway. With that, patch.lua becomes the single source of truth for process-wide cjson defaults, and the two option lines in `core/json.lua` can simply be removed. I checked for blind spots: nothing under `apisix/cli/` requires `core.json`, so there's no code path that loads it without going through `init.lua`'s `patch()` 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]
