亮点
本周有两项更改会影响 request 的返回结果。非 UTF-8 网站的 response body 不再以乱码形式呈现，且经 validate 接受的非 200 response 终于被计为成功而非失败。我们还修复了客户 API 的几个安全漏洞。
新增功能
非 UTF-8 页面在 Single 上返回可读文本
如果你在保加利亚论坛、中国电商、日本新闻或任何使用 windows-1251、GBK、Big5 或 Shift_JIS 的网站上调用 Single，response body 以前会返回损坏的字节。底层的 HTTP 层硬编码了 UTF-8 解码器，因此西里尔字母页面会变成 промоции，并且在你的端无法恢复原始数据。
这已在 request 层得到修复。Single 现在会检测源字符集（通过 Content-Type header，然后是 <meta charset>，再是 <meta http-equiv>）并在 body 进入你的 JSON 数据包之前转码为 UTF-8。而 UTF-8 或 ASCII 页面则保持原样。图片或 PDF 等二进制内容绝不会被解码。如果你需要原始字节，returnBuffer: true 仍会返回原始 buffer。
默认开启。无需切换任何 flag。以前正常工作的页面仍然正常工作；以前返回垃圾数据的页面现在返回可读文本。浏览器用户也无需担心这一点；Chromium 会原生解码字符集。
validate 规则现在决定成功分类
当你在 request 上设置 validate（例如 validate.status.accept = [200, 403]）时，request 引擎其实已经遵守了你的规则，并在没有报错的情况下解析了 response。但我们上游的 outcome 分类器忽略了你的规则，将任何非字面量 200 的响应都归类为 application_fail。这导致了两个后果：你接受的 403 在 Dashboard 中显示为失败；由于只有成功才计费，这些已交付的 response 也没有被计费。
分类器现在会尊重 validate 的声明。无论状态码如何，只要引擎在没有错误的情况下解析了请求，带有 validate 的 request 就会被计为成功。不带 validate 的 request 行为与之前相同（仅在 200 时成功），因此旧路径不受影响。
仅向后生效的修复：历史数据保留其存储 of outcome，新 request 将正确分类。因此，如果你之前在明知有效的 response 上看到 App Fail，原因就在这里。
客户 API 安全加固
我们发布了针对客户 API 的 Wave 0 安全审查：
- CORS 现在限制为
https://foura.ai。以前的设置在发送凭证时会反射任何源，这是标准的 CSRF 配置。同源浏览器调用和你的服务端 API 调用不受影响。 - 你的 Activity 时间线背后的 metrics 路由 以前接受自由格式的
outcome过滤器，该过滤器会直接流入查询。现在它已被加入白名单，仅限已知的 outcome 值。虽然无法从普通账户中利用此漏洞，但仍然值得关闭。
这两项更改都没有改变任何 API 契约。在正常使用期间你不会注意到它们。但在任何人注意到之前发现并解决问题，仍然值得说出来。
Activity 标签与 Overview 保持一致
一个小改动。你 Dashboard 中的 Activity 表以前会渲染原始 outcome 字符串（如 Application_fail），而 Overview 状态条、圆环图和时间线则显示友好标签（App Fail）并对每个 outcome 进行颜色编码。相同的数据，两种呈现方式。现在它们已同步，均读取相同的标签 and 颜色映射，因此无论你在哪里查看，某一行的状态看起来都是一样的。
数据指标
本周没有带来新的延迟或成功率数据。这其中的大部分工作是正确性和安全性工作，其正确的衡量指标是“停止出错”而不是“跑得更快”。下周的简报应该会包含一些正在进行的项目的吞吐量数据。