使用 JSON 格式传输的 WebSocket 收到非 JSON 数据时，使用 1003 关闭码合理吗？
Kirscheis 2023 年 10 月 14 日 2156 次点击这是一个创建于 908 天前的主题，其中的信息可能已经有所发展或是发生改变。
在很久以前，我为我们小组实验室内部使用的一些 API 设计了一套 RESTful + WebSocket 架构的 API ，由于这套 API 基本上都是程序调用，所以全部使用了 JSON 来序化和传输数据。在 WebSocket 上当时写程序的时候没有考虑太多，因为 JWT 验证失败的时候按惯例是返回的 1008 Policy Violation，所以收到非 JSON 数据的时候就用了一个类似的 1003 Unsupported Data。
我的理解是凡是不支持的或者无效的数据都可以用 1003 ，但是今天和同事讨论的时候他认为 1xxx 只能用于底层实现，基本上只能由库代码返回，如果使用 JSON 格式传输的 WebSocket 收到非 JSON 数据时，应该使用一个自定义的 4xxx 代码。但是根据 RFC 的例子，文本协议的 WebSocket 收到 binary 数据又可以使用 1003 ，这很明显是库代码以外的应用。我俩一顿讨论，google 了半天也没有找到一个公认的说法。
道理上讲这个问题应该大家都遇见过，特来问问 v2 ，大家在生产代码里怎么规范这件事？
 | 1 ysc3839 2023 年 10 月 14 日 via Android “应该使用一个自定义的 4xxx 代码” 那这个代码的具体错误信息是什么？ |
 | 2 Nazz 2023 年 10 月 15 日 服务端能用 1003, 客户端不行, chrome 会报错: Failed to execute 'close' on 'WebSocket': The code must be either 1000, or between 3000 and 4999. 1003 is neither. |
| 3 Nazz 2023 年 10 月 15 日  1 我倾向于无脑 1000 或者使用 4000~4999 的自定义状态码, 能使服务端/客户端正常工作就好, 不想去过分纠结. 参考资料 https://developer.mozilla.org/zh-CN/docs/Web/API/CloseEvent#status_codes |
 | 4 SHF 2023 年 10 月 15 日 1 不合理，1003 只能用于底层实现，使用自定义的吧 4000 ~ 4999 吧 |
Select Language