Richard Chien

验证了，这个问题确实存在，似乎是 libiconv 的 bug，我得再想想怎么弄

CQHTTP 用的 libcurl 没记错的话确实用的是系统的 WinSSL，系统版本较旧的话，确实可能出问题，建议换新系统试试

初步设计： ``` GET /r/info # 获取登录号信息 GET /r/friends # 好友列表 GET /r/friends/1002647525 # 好友信息（如果不在好友列表中则返回 404） POST /r/friends/1002647525/message # 发送私聊消息 GET /r/groups # 群组列表 GET /r/groups/530812134 # 群组信息 PUT /r/groups/530812134 #...

发送消息的 API 用 `POST /friends/123456/messages` 这样可能更好（`messages` 使用复数）？ 「更改群组设置」和「更改群成员信息」也许用 `PATCH` 更合理。另外，也可以把这里所谓的「设置」都分离出来，作为 `/groups/12345` 的子资源，如 `/groups/12345/banned`、`/groups/12345/members/123456/banned`、`/groups/12345/anonymous`，这里需要详细判断一下，像对于群成员信息那一条，可能使用 PATCH 来直接更新会更直观一些

@FETE-CH 你看这是两年前的 issue（到现在我还没开始，先不要抱太高期望😂

目前确实没有办法通过正向和反向 WebSocket 来获取 data 目录的内容，这可能需要考虑一下 不知道 WebSocket 在一个很大的 message 在连接上传输的情况下能不能同时传输其它内容，如果能的话，可以做一下，不能的话这可能会造成在获取语音文件的时候无法处理其它请求

还有一个问题，用 WebSocket 往回发文件，似乎无法标记对应的请求了？除非把文件 Base64 之后放在 JSON 里，或者还有另一种办法，让插件直接给某个指定的 HTTP 地址上传文件，这个还需要想一想。

> 不過語音文件發送的方向是由插件到用戶後端，不應該影響到處理請求（後端向插件）的吧？除非插件端用的是阻斷式 socket，必須等待文件寫入底層 buffer，才能回頭來處理請求？ 我隐约记得 WebSocket 是会建立两个通道，一个来一个去？如果是这样的话，调用 API 请求文件之后，文件占用了插件到后端的通道，此后的 API 调用虽然可以成功，但后端会潜在地需要很久之后才收到调用结果？

目前一个问题是如果 OneBot 实现端跑在 Deno 或浏览器中，发起反向 WS 连接也无法设置 header，所以需要允许实现端也可以通过 `access_token` 传递 token。 另外还有 `X-OneBot-Version` `X-Impl` `X-Platform` `X-Self-ID` 几个 header，可以使用 WebSocket 的 `Sec-WebSocket-Protocol` 头来传递，也就是 #164 的建议。

RFC 内容已更新，同时提了 #204，两者共同解决不能操作 WebSocket 请求头的问题