refactor: HTTP checker 质量加固
- failure actual 截断格式改为 …(共 N 字符)，标量不序列化直接返回 - 新增 redos.ts 实现 ReDoS 静态检测（嵌套量词/重叠交替），启动期拒绝危险正则 - JSON body rules 共享同一次 JSON.parse 结果，避免重复解析 - checkCssRule 重构为线性流程，消除 exist:true 与无 operator 的冗余分支 - extract checkEarlyTimeout 辅助函数，明确提前 duration 检查意图 - 补充 303/307/308 重定向、相对路径 Location、混合 body rules 集成测试
This commit is contained in:
@@ -1,2 +0,0 @@
|
||||
schema: spec-driven
|
||||
created: 2026-05-13
|
||||
@@ -1,93 +0,0 @@
|
||||
## Context
|
||||
|
||||
HTTP checker 是 DiAL 拨测系统的核心 runner 之一，负责对 HTTP 目标执行请求并校验响应。经审查发现以下质量问题：
|
||||
|
||||
1. **actual 值截断格式不符合 spec**：spec 要求 failure 中的 actual 摘要需截断并附带字符计数，但当前 `truncateActual` 函数只加省略号无计数，导致用户无法判断原始响应体规模。
|
||||
2. **ReDoS 风险**：用户配置的 regex body 规则和 match operator 直接对大响应体执行 `new RegExp().test()`，恶意或不当正则可能导致 CPU 阻塞。
|
||||
3. **JSON 重复解析**：多条 json body 规则各自独立调用 `JSON.parse(body)`，对大 JSON 响应体造成不必要的重复开销。
|
||||
4. **CSS 规则分支冗余**：`checkCssRule` 中"无 operator 时检查元素存在"和"exists: true"是重复逻辑。
|
||||
5. **重定向测试不足**：303、307/308、相对路径 Location 等分支缺少测试覆盖。
|
||||
|
||||
当前代码结构：
|
||||
- `src/server/checker/expect/failure.ts` — failure 构造函数
|
||||
- `src/server/checker/runner/http/body.ts` — body 规则检查
|
||||
- `src/server/checker/runner/http/execute.ts` — HTTP 执行主流程
|
||||
- `src/server/checker/expect/operator.ts` — operator 匹配逻辑
|
||||
|
||||
## Goals / Non-Goals
|
||||
|
||||
**Goals:**
|
||||
- 实现 failure actual 值截断，满足 spec 要求
|
||||
- 消除 regex 相关的 ReDoS 风险
|
||||
- 优化多条 JSON 规则的解析性能
|
||||
- 精简冗余代码分支
|
||||
- 补全重定向和集成测试覆盖
|
||||
|
||||
**Non-Goals:**
|
||||
- 不改变 CheckResult / CheckFailure 的类型结构（截断在构造时完成，对外接口不变）
|
||||
- 不引入新依赖
|
||||
- 不改变 HTTP checker 的功能行为（纯内部质量改进）
|
||||
- 不添加 response timing 分段记录（暂缓）
|
||||
- 不添加重试机制（拨测场景下重试会掩盖网络问题信号）
|
||||
|
||||
## Decisions
|
||||
|
||||
### Decision 1: actual 截断在 mismatchFailure 构造点统一实施
|
||||
|
||||
**选择**：在 `expect/failure.ts` 的 `mismatchFailure` 函数内部对 actual 参数截断，阈值 200 字符。
|
||||
|
||||
**替代方案**：
|
||||
- 在存储层（store.ts insertCheckResult）截断 — 但这样 API 实时返回的 failure 仍然很大
|
||||
- 在每个调用点手动截断 — 分散且容易遗漏
|
||||
|
||||
**理由**：构造点截断是最集中的拦截位置，所有 mismatch failure 都经过此函数，一处修改全局生效。expected 值不截断（来自用户配置，通常很短）。
|
||||
|
||||
**截断格式**：`<前 200 字符>…(共 N 字符)` — 保留前缀便于诊断，附带总长度便于判断规模（省略号为单字符 U+2026）。
|
||||
|
||||
### Decision 2: ReDoS 防护使用正则复杂度静态检测
|
||||
|
||||
**选择**：在启动期 validate 阶段对 regex body 规则和 match operator 进行静态复杂度检测，拒绝含有嵌套量词等危险模式的正则。运行期不做额外防护。
|
||||
|
||||
**替代方案**：
|
||||
- 运行期用 AbortSignal + setTimeout 强制中断 — Bun 的 RegExp 执行不可中断，无法实现
|
||||
- 使用 safe-regex 库 — 引入新依赖，违反项目规范
|
||||
- 限制正则执行的输入长度 — 会影响正常大响应体的匹配
|
||||
|
||||
**理由**：自行实现轻量级检测函数，检查常见 ReDoS 模式（嵌套量词 `(a+)+`、重叠交替 `(a|a)*`）。在 validate 阶段拒绝危险正则，比运行期防护更可靠——配置错误应该在启动时暴露。
|
||||
|
||||
**检测规则**：
|
||||
- 嵌套量词：量词内包含量词（如 `(a+)+`、`(a*)*`、`(a+)*`）
|
||||
- 重叠字符类交替后跟量词：`(x|x)+` 模式
|
||||
|
||||
### Decision 3: JSON parse 结果缓存在 checkBodyExpect 层
|
||||
|
||||
**选择**：在 `checkBodyExpect` 函数中，首次遇到 json 规则时执行 `JSON.parse`，将结果缓存并传递给后续 json 规则复用。
|
||||
|
||||
**实现方式**：修改 `checkSingleBodyRule` 签名，接受可选的 `parsedJson` 参数；在 `checkBodyExpect` 循环中维护一个 `let parsedJson: { ok: boolean; value?: unknown; error?: string }` 状态。
|
||||
|
||||
**理由**：改动最小，不改变外部接口，只在内部传递缓存。对于非 json 规则（contains、regex、css、xpath）无影响。
|
||||
|
||||
### Decision 4: CSS 规则分支合并策略
|
||||
|
||||
**选择**：将 `checkCssRule` 重构为线性流程：
|
||||
1. 解析 HTML
|
||||
2. 处理 `exists: false`（元素不存在即通过）
|
||||
3. 查找元素（不存在则失败）
|
||||
4. 处理 `exists: true`（到这里已确认存在，直接通过）
|
||||
5. 提取值（attr 或 text）
|
||||
6. 无 operator 时检查值非 undefined 即通过
|
||||
7. 有 operator 时执行匹配
|
||||
|
||||
**理由**：消除当前三层嵌套判断中的重复逻辑，使控制流线性化，更易理解和维护。
|
||||
|
||||
### Decision 5: execute.ts 提前 duration 检查保留但加注释
|
||||
|
||||
**选择**：保留第 56-74 行的提前 duration 检查逻辑（它是有效的性能优化——避免读取注定超时的 body），但重构为独立的 helper 函数使意图更明确。
|
||||
|
||||
**理由**：删除它会导致超时场景下仍然读取完整 body 后才报错，浪费网络带宽和时间。提取为 `checkEarlyTimeout` 函数名即可自解释。
|
||||
|
||||
## Risks / Trade-offs
|
||||
|
||||
- **ReDoS 静态检测的误报**：过于严格的检测可能拒绝合法但看起来复杂的正则。→ 缓解：只检测最常见的嵌套量词模式，不做过度分析；提供清晰的错误信息指导用户修改。
|
||||
- **actual 截断丢失诊断信息**：截断后用户无法看到完整 actual 值。→ 缓解：200 字符的前缀通常足够定位问题；如需完整响应体，用户应直接请求目标 URL 查看。
|
||||
- **JSON parse 缓存的内存占用**：对于大 JSON 响应体，缓存的 parsed 对象会在整个 body rules 检查期间驻留内存。→ 缓解：这是短暂的（单次检查周期内），且原本每条规则都会各自 parse 一份，缓存反而减少了峰值内存。
|
||||
@@ -1,28 +0,0 @@
|
||||
## Why
|
||||
|
||||
HTTP checker 经过审查发现若干质量问题：failure 中 actual 值截断格式不符合 spec 要求（缺少字符计数）导致诊断信息不完整、regex 规则缺少 ReDoS 防护存在 CPU 阻塞风险、多条 JSON body 规则重复 parse 造成不必要开销、CSS 规则分支冗余、重定向测试覆盖不足。需要统一修复以提升健壮性和代码质量。
|
||||
|
||||
## What Changes
|
||||
|
||||
- 修正 `mismatchFailure` 中 actual 值截断格式，添加字符计数信息，格式为 `前 N 字符…(共 M 字符)`
|
||||
- 为 regex body 规则和 match operator 添加 ReDoS 防护（执行超时或正则复杂度检测）
|
||||
- 优化多条 JSON body 规则共享同一次 `JSON.parse` 结果，避免重复解析
|
||||
- 精简 `body.ts` 中 `checkCssRule` 的冗余分支逻辑
|
||||
- 精简 `execute.ts` 中提前 duration 检查的代码结构
|
||||
- 补充重定向相关测试：303 method 转换、307/308 保持 method、相对路径 Location、混合 body rules 集成测试
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
|
||||
### Modified Capabilities
|
||||
- `expect-body-checkers`: 新增 actual 值截断的具体实现要求（spec 已声明但未细化截断阈值和格式）
|
||||
|
||||
## Impact
|
||||
|
||||
- `src/server/checker/expect/failure.ts` — 新增截断逻辑
|
||||
- `src/server/checker/runner/http/body.ts` — JSON parse 优化、CSS 分支精简
|
||||
- `src/server/checker/runner/http/execute.ts` — duration 检查精简
|
||||
- `src/server/checker/expect/operator.ts` — match operator ReDoS 防护
|
||||
- `tests/server/checker/runner/http/runner.test.ts` — 补充重定向和集成测试
|
||||
- `tests/server/checker/runner/shared/body.test.ts` — 补充截断相关测试
|
||||
@@ -1,101 +0,0 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
> 注：仅展示变更的 scenarios，其余 scenarios 保持不变
|
||||
|
||||
### Requirement: 结构化 expect 失败信息
|
||||
系统 SHALL 在任一 expect 规则失败时生成结构化 failure，用于标识失败阶段、规则路径、期望值、实际值和可读错误信息。actual 值 SHALL 在构造时截断至不超过 200 字符，超出部分以省略标记和总字符数替代。expected 值不截断。
|
||||
|
||||
#### Scenario: body 规则失败信息
|
||||
- **WHEN** HTTP target 的 `expect.body[1].json` 规则失败
|
||||
- **THEN** failure SHALL 包含 kind=`mismatch`、phase=`body`、path 指向 `expect.body[1]`，并包含 message
|
||||
|
||||
#### Scenario: actual 值截断
|
||||
- **WHEN** 失败规则的实际值为字符串且长度超过 200 字符
|
||||
- **THEN** failure.actual SHALL 为前 200 字符加 `…(共 N 字符)` 后缀，其中 N 为原始总字符数
|
||||
|
||||
#### Scenario: actual 值未超限
|
||||
- **WHEN** 失败规则的实际值为字符串且长度不超过 200 字符
|
||||
- **THEN** failure.actual SHALL 保留完整原始值，不做截断
|
||||
|
||||
#### Scenario: actual 值为对象或数组
|
||||
- **WHEN** 失败规则的实际值为对象或数组，且 JSON 序列化后长度超过 200 字符
|
||||
- **THEN** failure.actual SHALL 为序列化后前 200 字符加 `…(共 N 字符)` 后缀
|
||||
|
||||
#### Scenario: actual 值为标量
|
||||
- **WHEN** 失败规则的实际值为 number、boolean、null 或 undefined
|
||||
- **THEN** failure.actual SHALL 保留原始值，不做截断
|
||||
|
||||
### Requirement: HTTP expect 规则启动期校验
|
||||
系统 SHALL 在启动期校验 HTTP expect 中已支持字段的类型、格式、未知字段和可编译表达式。HTTP expect、body rule、json/css/xpath rule 和 operator 对象中的未知字段 SHALL 导致启动期配置失败。每个 body rule 对象 MUST 恰好包含 contains、regex、json、css、xpath 中的一种规则类型。纯 operator 对象 MUST 至少包含一个已知 operator；body 提取规则可以不配置 operator，并以路径、元素或节点存在作为通过语义。`equals` operator SHALL 支持任意 JSON value，包括数组和对象。系统 SHALL 在启动期对 regex body 规则和 match operator 的正则表达式进行 ReDoS 安全检测，含有嵌套量词等危险模式的正则 SHALL 导致启动期配置失败。
|
||||
|
||||
#### Scenario: body rule 使用 regex 字段
|
||||
- **WHEN** HTTP target 配置 `expect.body: [{regex: "ok|healthy"}]` 且 regex 可编译且无 ReDoS 风险
|
||||
- **THEN** 系统 SHALL 接受该配置，并在运行期按 regex body 规则匹配响应体
|
||||
|
||||
#### Scenario: body rule 不支持 match 字段
|
||||
- **WHEN** HTTP target 配置 `expect.body: [{match: "ok"}]` 且该规则没有 contains、regex、json、css、xpath 任一支持字段
|
||||
- **THEN** 系统 SHALL 在启动期配置校验失败
|
||||
|
||||
#### Scenario: body rule 未知字段启动失败
|
||||
- **WHEN** HTTP target 配置 `expect.body: [{contains: "ok", note: "ignored"}]`
|
||||
- **THEN** 系统 SHALL 在启动期配置校验失败，提示 `note` 是未知字段
|
||||
|
||||
#### Scenario: body rule 多支持字段非法
|
||||
- **WHEN** HTTP target 的同一条 body rule 同时配置 contains 和 regex
|
||||
- **THEN** 系统 SHALL 在启动期配置校验失败
|
||||
|
||||
#### Scenario: operator match 正则非法
|
||||
- **WHEN** HTTP target 的 expect.headers、json、css 或 xpath operator 配置了不可编译的 match 正则
|
||||
- **THEN** 系统 SHALL 在启动期配置校验失败
|
||||
|
||||
#### Scenario: operator 数值比较类型非法
|
||||
- **WHEN** HTTP target 的 expect operator 配置 gt、gte、lt 或 lte，且对应值不是有限数字
|
||||
- **THEN** 系统 SHALL 在启动期配置校验失败
|
||||
|
||||
#### Scenario: operator 布尔类型非法
|
||||
- **WHEN** HTTP target 的 expect operator 配置 empty 或 exists，且对应值不是布尔值
|
||||
- **THEN** 系统 SHALL 在启动期配置校验失败
|
||||
|
||||
#### Scenario: JSONPath 子集非法
|
||||
- **WHEN** HTTP target 的 json body rule path 不符合系统支持的 JSONPath 子集
|
||||
- **THEN** 系统 SHALL 在启动期配置校验失败
|
||||
|
||||
#### Scenario: operator 未知字段非法
|
||||
- **WHEN** HTTP target 的 expect operator 配置了 `foo: "bar"` 等未知 operator 字段
|
||||
- **THEN** 系统 SHALL 在启动期配置校验失败
|
||||
|
||||
#### Scenario: equals 支持对象
|
||||
- **WHEN** HTTP target 配置 `expect.body: [{json: {path: "$.payload", equals: {status: "ok"}}}]`
|
||||
- **THEN** 系统 SHALL 接受该配置，并在运行期使用深度相等比较提取值和对象期望
|
||||
|
||||
#### Scenario: equals 支持数组
|
||||
- **WHEN** HTTP target 配置 `expect.body: [{json: {path: "$.items", equals: ["a", "b"]}}]`
|
||||
- **THEN** 系统 SHALL 接受该配置，并在运行期使用深度相等比较提取值和数组期望
|
||||
|
||||
#### Scenario: 纯 operator 对象不能为空
|
||||
- **WHEN** HTTP target 的 `expect.headers` 中某个 header 期望配置为空对象 `{}`
|
||||
- **THEN** 系统 SHALL 在启动期配置校验失败，要求显式配置至少一个 operator
|
||||
|
||||
#### Scenario: json rule 允许存在性语义
|
||||
- **WHEN** HTTP target 配置 `expect.body: [{json: {path: "$.status"}}]`
|
||||
- **THEN** 系统 SHALL 接受该配置，并在运行期以 JSONPath 值存在作为通过语义
|
||||
|
||||
#### Scenario: css rule 未知字段非法
|
||||
- **WHEN** HTTP target 配置 `expect.body: [{css: {selector: "h1", unknown: true}}]`
|
||||
- **THEN** 系统 SHALL 在启动期配置校验失败，提示未知字段
|
||||
|
||||
#### Scenario: xpath rule 未知字段非法
|
||||
- **WHEN** HTTP target 配置 `expect.body: [{xpath: {path: "/html/body", unknown: true}}]`
|
||||
- **THEN** 系统 SHALL 在启动期配置校验失败，提示未知字段
|
||||
|
||||
#### Scenario: regex body 规则含嵌套量词启动失败
|
||||
- **WHEN** HTTP target 配置 `expect.body: [{regex: "(a+)+$"}]`
|
||||
- **THEN** 系统 SHALL 在启动期配置校验失败，提示正则存在 ReDoS 风险
|
||||
|
||||
#### Scenario: match operator 含嵌套量词启动失败
|
||||
- **WHEN** HTTP target 的 expect operator 配置 `{match: "(\\d+)*x"}`
|
||||
- **THEN** 系统 SHALL 在启动期配置校验失败，提示正则存在 ReDoS 风险
|
||||
|
||||
#### Scenario: 安全正则通过校验
|
||||
- **WHEN** HTTP target 配置 `expect.body: [{regex: "\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}"}]`
|
||||
- **THEN** 系统 SHALL 接受该配置（无嵌套量词，无 ReDoS 风险）
|
||||
@@ -1,38 +0,0 @@
|
||||
## 1. failure actual 截断
|
||||
|
||||
- [ ] 1.1 修改 `src/server/checker/expect/failure.ts` 中 `truncateActual` 函数，截断后缀从 `...` 改为 `…(共 N 字符)`，其中省略号为单字符 U+2026
|
||||
- [ ] 1.2 更新 `tests/server/checker/runner/shared/failure.test.ts` 中截断相关测试断言，匹配新格式（检查省略号为单字符且带字符计数）
|
||||
|
||||
## 2. ReDoS 防护
|
||||
|
||||
- [ ] 2.1 在 `src/server/checker/expect/` 下新增 `redos.ts`，实现 `isUnsafeRegex(pattern: string): boolean` 函数，检测嵌套量词模式
|
||||
- [ ] 2.2 在 `src/server/checker/runner/http/validate.ts` 的 `validateRegexRule` 和 `src/server/checker/expect/validate-operator.ts` 的 match 校验中调用 `isUnsafeRegex`，不安全时返回 issue
|
||||
- [ ] 2.3 在 `tests/server/checker/runner/http/runner.test.ts` 中补充 ReDoS 正则启动校验失败的测试用例
|
||||
- [ ] 2.4 在 `tests/server/checker/runner/shared/` 下新增 `redos.test.ts`，覆盖常见 ReDoS 模式和安全正则的判定
|
||||
|
||||
## 3. JSON parse 优化
|
||||
|
||||
- [ ] 3.1 修改 `src/server/checker/runner/http/body.ts` 中 `checkBodyExpect` 函数，维护 parsedJson 缓存状态，首次 json 规则 parse 后复用结果
|
||||
- [ ] 3.2 修改 `checkJsonRule` 签名接受可选的预解析 JSON 对象，避免重复 `JSON.parse`
|
||||
- [ ] 3.3 在 `tests/server/checker/runner/shared/body.test.ts` 中补充多条 json 规则共享 parse 结果的测试（验证行为正确性）
|
||||
|
||||
## 4. CSS 规则精简
|
||||
|
||||
- [ ] 4.1 重构 `src/server/checker/runner/http/body.ts` 中 `checkCssRule` 为线性流程：解析 HTML → exists:false 短路 → 查找元素 → exists:true 短路 → 提取值 → operator 匹配
|
||||
- [ ] 4.2 确认 `tests/server/checker/runner/shared/body.test.ts` 中现有 CSS 测试全部通过
|
||||
|
||||
## 5. execute.ts 精简
|
||||
|
||||
- [ ] 5.1 将 `src/server/checker/runner/http/execute.ts` 第 56-74 行的提前 duration 检查提取为 `checkEarlyTimeout` 辅助函数，明确意图
|
||||
|
||||
## 6. 补充测试
|
||||
|
||||
- [ ] 6.1 在 `tests/server/checker/runner/http/runner.test.ts` 中补充 303 重定向 method 转 GET 的测试
|
||||
- [ ] 6.2 在 `tests/server/checker/runner/http/runner.test.ts` 中补充 307/308 保持原始 method 和 body 的测试
|
||||
- [ ] 6.3 在 `tests/server/checker/runner/http/runner.test.ts` 中补充相对路径 Location header 重定向的测试
|
||||
- [ ] 6.4 在 `tests/server/checker/runner/http/runner.test.ts` 中补充混合 body rules（contains + json + css）集成测试
|
||||
|
||||
## 7. 质量保障
|
||||
|
||||
- [ ] 7.1 执行完整测试套件 `bun test`、代码检查 `bun run lint`、格式检查 `bun run format:check` 确保无回归
|
||||
- [ ] 7.2 更新 DEVELOPMENT.md 中 ReDoS 校验相关说明（如有必要）
|
||||
@@ -117,15 +117,27 @@
|
||||
- **THEN** 系统 SHALL 判定 matched 为 false
|
||||
|
||||
### Requirement: 结构化 expect 失败信息
|
||||
系统 SHALL 在任一 expect 规则失败时生成结构化 failure，用于标识失败阶段、规则路径、期望值、实际值和可读错误信息。
|
||||
系统 SHALL 在任一 expect 规则失败时生成结构化 failure，用于标识失败阶段、规则路径、期望值、实际值和可读错误信息。actual 值 SHALL 在构造时截断至不超过 200 字符，超出部分以省略标记和总字符数替代。expected 值不截断。
|
||||
|
||||
#### Scenario: body 规则失败信息
|
||||
- **WHEN** HTTP target 的 `expect.body[1].json` 规则失败
|
||||
- **THEN** failure SHALL 包含 kind=`mismatch`、phase=`body`、path 指向 `expect.body[1]`，并包含 message
|
||||
|
||||
#### Scenario: actual 值截断
|
||||
- **WHEN** 失败规则的实际值超过系统允许记录的摘要长度
|
||||
- **THEN** 系统 MUST 截断 actual 摘要，而不是持久化完整响应体或命令输出
|
||||
- **WHEN** 失败规则的实际值为字符串且长度超过 200 字符
|
||||
- **THEN** failure.actual SHALL 为前 200 字符加 `…(共 N 字符)` 后缀，其中 N 为原始总字符数
|
||||
|
||||
#### Scenario: actual 值未超限
|
||||
- **WHEN** 失败规则的实际值为字符串且长度不超过 200 字符
|
||||
- **THEN** failure.actual SHALL 保留完整原始值，不做截断
|
||||
|
||||
#### Scenario: actual 值为对象或数组
|
||||
- **WHEN** 失败规则的实际值为对象或数组，且 JSON 序列化后长度超过 200 字符
|
||||
- **THEN** failure.actual SHALL 为序列化后前 200 字符加 `…(共 N 字符)` 后缀
|
||||
|
||||
#### Scenario: actual 值为标量
|
||||
- **WHEN** 失败规则的实际值为 number、boolean、null 或 undefined
|
||||
- **THEN** failure.actual SHALL 保留原始值，不做截断
|
||||
|
||||
### Requirement: 状态码范围匹配
|
||||
系统 SHALL 支持在 `expect.status` 数组中使用范围模式字符串（`"1xx"`、`"2xx"`、`"3xx"`、`"4xx"`、`"5xx"`），与精确数字混合使用。范围模式 SHALL 匹配对应百位段内的所有状态码。其他范围模式 SHALL 在启动期配置校验失败。
|
||||
@@ -163,10 +175,10 @@
|
||||
- **THEN** 系统 SHALL 在启动期配置校验失败
|
||||
|
||||
### Requirement: HTTP expect 规则启动期校验
|
||||
系统 SHALL 在启动期校验 HTTP expect 中已支持字段的类型、格式、未知字段和可编译表达式。HTTP expect、body rule、json/css/xpath rule 和 operator 对象中的未知字段 SHALL 导致启动期配置失败。每个 body rule 对象 MUST 恰好包含 contains、regex、json、css、xpath 中的一种规则类型。纯 operator 对象 MUST 至少包含一个已知 operator；body 提取规则可以不配置 operator，并以路径、元素或节点存在作为通过语义。`equals` operator SHALL 支持任意 JSON value，包括数组和对象。
|
||||
系统 SHALL 在启动期校验 HTTP expect 中已支持字段的类型、格式、未知字段和可编译表达式。HTTP expect、body rule、json/css/xpath rule 和 operator 对象中的未知字段 SHALL 导致启动期配置失败。每个 body rule 对象 MUST 恰好包含 contains、regex、json、css、xpath 中的一种规则类型。纯 operator 对象 MUST 至少包含一个已知 operator；body 提取规则可以不配置 operator，并以路径、元素或节点存在作为通过语义。`equals` operator SHALL 支持任意 JSON value，包括数组和对象。系统 SHALL 在启动期对 regex body 规则和 match operator 的正则表达式进行 ReDoS 安全检测，含有嵌套量词等危险模式的正则 SHALL 导致启动期配置失败。
|
||||
|
||||
#### Scenario: body rule 使用 regex 字段
|
||||
- **WHEN** HTTP target 配置 `expect.body: [{regex: "ok|healthy"}]` 且 regex 可编译
|
||||
- **WHEN** HTTP target 配置 `expect.body: [{regex: "ok|healthy"}]` 且 regex 可编译且无 ReDoS 风险
|
||||
- **THEN** 系统 SHALL 接受该配置，并在运行期按 regex body 规则匹配响应体
|
||||
|
||||
#### Scenario: body rule 不支持 match 字段
|
||||
@@ -225,6 +237,18 @@
|
||||
- **WHEN** HTTP target 配置 `expect.body: [{xpath: {path: "/html/body", unknown: true}}]`
|
||||
- **THEN** 系统 SHALL 在启动期配置校验失败，提示未知字段
|
||||
|
||||
#### Scenario: regex body 规则含嵌套量词启动失败
|
||||
- **WHEN** HTTP target 配置 `expect.body: [{regex: "(a+)+$"}]`
|
||||
- **THEN** 系统 SHALL 在启动期配置校验失败，提示正则存在 ReDoS 风险
|
||||
|
||||
#### Scenario: match operator 含嵌套量词启动失败
|
||||
- **WHEN** HTTP target 的 expect operator 配置 `{match: "(\\d+)*x"}`
|
||||
- **THEN** 系统 SHALL 在启动期配置校验失败，提示正则存在 ReDoS 风险
|
||||
|
||||
#### Scenario: 安全正则通过校验
|
||||
- **WHEN** HTTP target 配置 `expect.body: [{regex: "\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}"}]`
|
||||
- **THEN** 系统 SHALL 接受该配置（无嵌套量词，无 ReDoS 风险）
|
||||
|
||||
### Requirement: HTTP body 运行期失败结构化
|
||||
系统 SHALL 将 HTTP body 运行期失败记录为结构化 CheckFailure，并保留与具体规则相关的 phase 和 path。响应内容不符合配置 SHALL 记录为 mismatch；响应内容无法按配置解析或解码 SHALL 记录为 error。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user