bzp2010 opened a new pull request, #13972:
URL: https://github.com/apache/apisix/pull/13972
### Description
#13939 added the `ws`/`wss` upstream scheme, which proxies WebSocket frames
itself instead of letting nginx's `proxy_pass` relay raw bytes. That review
flagged that a single frame over 65535 bytes closes the connection, because
`resty.websocket.proxy` builds its client/server instances with no options and
both default `max_payload_len` to 65535; `enable_websocket` has no such limit,
since it never parses frames at all. The reviewer verified this against the
same upstream (client -> APISIX -> echo server that reports the received
length): a 65536-byte frame is echoed back fine with `enable_websocket`, but
closes the connection (`failed to receive the first 2 bytes: closed`) with
`scheme: ws`.
That review thread's reply said this would follow in its own PR, once
`api7-lua-resty-websocket` could pass the option through and once there was a
way to configure it per route rather than per upstream. Both are done now: the
library published 0.2.0 with `client_new_opts`/`upstream_new_opts` on
`resty.websocket.proxy.new()`, and this PR adds a plugin to configure them per
route, the same way `kafka-proxy` configures kafka-scheme upstreams.
#### What changed
- Bumped `api7-lua-resty-websocket` to `0.2.0-0`. New in this release:
`resty.websocket.proxy.new()` accepts `client_new_opts`/`upstream_new_opts`,
passed through as-is to the `resty.websocket.server`/`resty.websocket.client`
constructors on each side of the proxy ("client" facing the real downstream
client, "upstream" facing the backend, same naming the library already used for
`client_max_frame_size`/`upstream_max_frame_size`).
- Added the `websocket-proxy` plugin (modeled on `kafka-proxy`):
`client_max_payload_len`/`upstream_max_payload_len`, written onto `ctx` in the
`ws_handshake` phase. `apisix/init.lua` reads them when building
`client_new_opts`/`upstream_new_opts` for `ws_proxy.new()`; left unset, the
65535 default is unchanged.
- Only `max_payload_len` is exposed for now, not the full options table.
`client_new_opts`/`upstream_new_opts` also accept `timeout` (which would fight
the existing `upstream.timeout.connect`/`.read`-driven timeout handling) and
`send_unmasked` (a protocol-correctness flag per RFC 6455 ยง5.1, not a safe
thing to expose unchecked). Both are left out deliberately;
`max_recv_len`/`max_send_len` were left out too since nothing asked for
asymmetric send/receive limits yet, but can follow the same pattern later if
needed.
#### Which issue(s) this PR fixes
Addresses the frame size limitation flagged on #13939:
https://github.com/apache/apisix/pull/13939#discussion_r4013893671, with the
follow-up plan from
https://github.com/apache/apisix/pull/13939#discussion_r4022229975.
### 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
- [x] I have updated the documentation to reflect this change
- [x] I have verified that this change is backward compatible
--
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]
