fix: improve suffix range and open-ended range handling by sendya · Pull Request #64 · omalloc/tavern

sendya · 2026-07-06T14:47:16Z

概述

修复 issue #63 — 客户端发送 suffix range（如 Range: bytes=-512）时的两个 bug：

multirange 中间件错误拒绝 suffix range：原有代码对所有 rangecontrol.Parse 失败都返回 416，但 suffix range 是 RFC 7233 合法的 HTTP Range 格式，multirange 不应拦截单 suffix range。
fillRange 将 suffix range 计算为 MaxInt64 无效范围：未知对象大小时用 math.MaxInt64 推导 suffix range 起始位置，导致生成天文数字的 Range 头发送到上游。

修改内容

P0: multirange 透传单 suffix range

使用 rangecontrol.Parse(rawRange, math.MaxInt32) 替代自定义 hasSuffixRange
单 range（含 suffix range）透传到下一层
无效 range（如 bytes=abc, bytes=-）返回 416
混合 suffix multi-range（如 bytes=0-99,-512）在未知对象大小时拒绝

P0: fillRange 绕过不可解析 range

hasSuffixRange → hasUnresolvableRange，同时检测 suffix range 和 open-ended range
未知对象大小时绕过，避免 MaxInt64 计算

P0: rangecontrol.Parse 支持 totalSize

接受 totalSize 参数以解析 suffix range
suffix range 超过对象大小时跳过（而非生成负数 start）

其他

internal.go: 新增 rng nil 检查防止 panic
新增 benchmark 测试

边界情况

场景	修复前	修复后
`bytes=-512` cache MISS	MaxInt64 无效范围	透传到上游
`bytes=-512` cache HIT	416	使用已知 Size 正确返回
`bytes= -512`	可能异常	识别为 suffix range 透传
`bytes=0-99,-512`	可能被错误处理	未知大小时 416
`bytes=100-` cache MISS	MaxInt64 无效范围	透传到上游
`bytes=abc`	416	保持 416

Closes#63

🤖 Generated with Claude Code

… middleware

- rangecontrol.Parse now accepts totalSize to resolve suffix ranges and open-ended ranges; skips suffix ranges exceeding total size - fillRange: rename hasSuffixRange to hasUnresolvableRange and also detect open-ended ranges; bypass when object size is unknown - internal.go: add nil check for rng before accessing rng.End - multirange: use rangecontrol.Parse for proper range detection; single suffix ranges pass through to next layer; return 416 for truly unresolvable ranges (unknown objSize without Content-Range) - Add benchmark tests for Parse, ParseRange, and ContentRange Co-Authored-By: Claude <noreply@anthropic.com>

sendya · 2026-07-06T14:47:16Z

概述

修复 issue #63 — 客户端发送 suffix range（如 Range: bytes=-512）时的两个 bug：

multirange 中间件错误拒绝 suffix range：原有代码对所有 rangecontrol.Parse 失败都返回 416，但 suffix range 是 RFC 7233 合法的 HTTP Range 格式，multirange 不应拦截单 suffix range。
fillRange 将 suffix range 计算为 MaxInt64 无效范围：未知对象大小时用 math.MaxInt64 推导 suffix range 起始位置，导致生成天文数字的 Range 头发送到上游。

修改内容

P0: multirange 透传单 suffix range

使用 rangecontrol.Parse(rawRange, math.MaxInt32) 替代自定义 hasSuffixRange
单 range（含 suffix range）透传到下一层
无效 range（如 bytes=abc, bytes=-）返回 416
混合 suffix multi-range（如 bytes=0-99,-512）在未知对象大小时拒绝

P0: fillRange 绕过不可解析 range

hasSuffixRange → hasUnresolvableRange，同时检测 suffix range 和 open-ended range
未知对象大小时绕过，避免 MaxInt64 计算

P0: rangecontrol.Parse 支持 totalSize

接受 totalSize 参数以解析 suffix range
suffix range 超过对象大小时跳过（而非生成负数 start）

其他

internal.go: 新增 rng nil 检查防止 panic
新增 benchmark 测试

边界情况

场景	修复前	修复后
`bytes=-512` cache MISS	MaxInt64 无效范围	透传到上游
`bytes=-512` cache HIT	416	使用已知 Size 正确返回
`bytes= -512`	可能异常	识别为 suffix range 透传
`bytes=0-99,-512`	可能被错误处理	未知大小时 416
`bytes=100-` cache MISS	MaxInt64 无效范围	透传到上游
`bytes=abc`	416	保持 416

Closes#63

🤖 Generated with Claude Code

… middleware

- rangecontrol.Parse now accepts totalSize to resolve suffix ranges and open-ended ranges; skips suffix ranges exceeding total size - fillRange: rename hasSuffixRange to hasUnresolvableRange and also detect open-ended ranges; bypass when object size is unknown - internal.go: add nil check for rng before accessing rng.End - multirange: use rangecontrol.Parse for proper range detection; single suffix ranges pass through to next layer; return 416 for truly unresolvable ranges (unknown objSize without Content-Range) - Add benchmark tests for Parse, ParseRange, and ContentRange Co-Authored-By: Claude <noreply@anthropic.com>

sendya · 2026-07-06T14:47:16Z

概述

修复 issue #63 — 客户端发送 suffix range（如 Range: bytes=-512）时的两个 bug：

multirange 中间件错误拒绝 suffix range：原有代码对所有 rangecontrol.Parse 失败都返回 416，但 suffix range 是 RFC 7233 合法的 HTTP Range 格式，multirange 不应拦截单 suffix range。
fillRange 将 suffix range 计算为 MaxInt64 无效范围：未知对象大小时用 math.MaxInt64 推导 suffix range 起始位置，导致生成天文数字的 Range 头发送到上游。

修改内容

P0: multirange 透传单 suffix range

使用 rangecontrol.Parse(rawRange, math.MaxInt32) 替代自定义 hasSuffixRange
单 range（含 suffix range）透传到下一层
无效 range（如 bytes=abc, bytes=-）返回 416
混合 suffix multi-range（如 bytes=0-99,-512）在未知对象大小时拒绝

P0: fillRange 绕过不可解析 range

hasSuffixRange → hasUnresolvableRange，同时检测 suffix range 和 open-ended range
未知对象大小时绕过，避免 MaxInt64 计算

P0: rangecontrol.Parse 支持 totalSize

接受 totalSize 参数以解析 suffix range
suffix range 超过对象大小时跳过（而非生成负数 start）

其他

internal.go: 新增 rng nil 检查防止 panic
新增 benchmark 测试

边界情况

场景	修复前	修复后
`bytes=-512` cache MISS	MaxInt64 无效范围	透传到上游
`bytes=-512` cache HIT	416	使用已知 Size 正确返回
`bytes= -512`	可能异常	识别为 suffix range 透传
`bytes=0-99,-512`	可能被错误处理	未知大小时 416
`bytes=100-` cache MISS	MaxInt64 无效范围	透传到上游
`bytes=abc`	416	保持 416

Closes#63

🤖 Generated with Claude Code

… middleware

- rangecontrol.Parse now accepts totalSize to resolve suffix ranges and open-ended ranges; skips suffix ranges exceeding total size - fillRange: rename hasSuffixRange to hasUnresolvableRange and also detect open-ended ranges; bypass when object size is unknown - internal.go: add nil check for rng before accessing rng.End - multirange: use rangecontrol.Parse for proper range detection; single suffix ranges pass through to next layer; return 416 for truly unresolvable ranges (unknown objSize without Content-Range) - Add benchmark tests for Parse, ParseRange, and ContentRange Co-Authored-By: Claude <noreply@anthropic.com>

sendya · 2026-07-06T14:47:16Z

概述

修复 issue #63 — 客户端发送 suffix range（如 Range: bytes=-512）时的两个 bug：

multirange 中间件错误拒绝 suffix range：原有代码对所有 rangecontrol.Parse 失败都返回 416，但 suffix range 是 RFC 7233 合法的 HTTP Range 格式，multirange 不应拦截单 suffix range。
fillRange 将 suffix range 计算为 MaxInt64 无效范围：未知对象大小时用 math.MaxInt64 推导 suffix range 起始位置，导致生成天文数字的 Range 头发送到上游。

修改内容

P0: multirange 透传单 suffix range

使用 rangecontrol.Parse(rawRange, math.MaxInt32) 替代自定义 hasSuffixRange
单 range（含 suffix range）透传到下一层
无效 range（如 bytes=abc, bytes=-）返回 416
混合 suffix multi-range（如 bytes=0-99,-512）在未知对象大小时拒绝

P0: fillRange 绕过不可解析 range

hasSuffixRange → hasUnresolvableRange，同时检测 suffix range 和 open-ended range
未知对象大小时绕过，避免 MaxInt64 计算

P0: rangecontrol.Parse 支持 totalSize

接受 totalSize 参数以解析 suffix range
suffix range 超过对象大小时跳过（而非生成负数 start）

其他

internal.go: 新增 rng nil 检查防止 panic
新增 benchmark 测试

边界情况

场景	修复前	修复后
`bytes=-512` cache MISS	MaxInt64 无效范围	透传到上游
`bytes=-512` cache HIT	416	使用已知 Size 正确返回
`bytes= -512`	可能异常	识别为 suffix range 透传
`bytes=0-99,-512`	可能被错误处理	未知大小时 416
`bytes=100-` cache MISS	MaxInt64 无效范围	透传到上游
`bytes=abc`	416	保持 416

Closes#63

🤖 Generated with Claude Code

… middleware

- rangecontrol.Parse now accepts totalSize to resolve suffix ranges and open-ended ranges; skips suffix ranges exceeding total size - fillRange: rename hasSuffixRange to hasUnresolvableRange and also detect open-ended ranges; bypass when object size is unknown - internal.go: add nil check for rng before accessing rng.End - multirange: use rangecontrol.Parse for proper range detection; single suffix ranges pass through to next layer; return 416 for truly unresolvable ranges (unknown objSize without Content-Range) - Add benchmark tests for Parse, ParseRange, and ContentRange Co-Authored-By: Claude <noreply@anthropic.com>

sendya · 2026-07-06T14:47:16Z

概述

修复 issue #63 — 客户端发送 suffix range（如 Range: bytes=-512）时的两个 bug：

multirange 中间件错误拒绝 suffix range：原有代码对所有 rangecontrol.Parse 失败都返回 416，但 suffix range 是 RFC 7233 合法的 HTTP Range 格式，multirange 不应拦截单 suffix range。
fillRange 将 suffix range 计算为 MaxInt64 无效范围：未知对象大小时用 math.MaxInt64 推导 suffix range 起始位置，导致生成天文数字的 Range 头发送到上游。

修改内容

P0: multirange 透传单 suffix range

使用 rangecontrol.Parse(rawRange, math.MaxInt32) 替代自定义 hasSuffixRange
单 range（含 suffix range）透传到下一层
无效 range（如 bytes=abc, bytes=-）返回 416
混合 suffix multi-range（如 bytes=0-99,-512）在未知对象大小时拒绝

P0: fillRange 绕过不可解析 range

hasSuffixRange → hasUnresolvableRange，同时检测 suffix range 和 open-ended range
未知对象大小时绕过，避免 MaxInt64 计算

P0: rangecontrol.Parse 支持 totalSize

接受 totalSize 参数以解析 suffix range
suffix range 超过对象大小时跳过（而非生成负数 start）

其他

internal.go: 新增 rng nil 检查防止 panic
新增 benchmark 测试

边界情况

场景	修复前	修复后
`bytes=-512` cache MISS	MaxInt64 无效范围	透传到上游
`bytes=-512` cache HIT	416	使用已知 Size 正确返回
`bytes= -512`	可能异常	识别为 suffix range 透传
`bytes=0-99,-512`	可能被错误处理	未知大小时 416
`bytes=100-` cache MISS	MaxInt64 无效范围	透传到上游
`bytes=abc`	416	保持 416

Closes#63

🤖 Generated with Claude Code

… middleware

- rangecontrol.Parse now accepts totalSize to resolve suffix ranges and open-ended ranges; skips suffix ranges exceeding total size - fillRange: rename hasSuffixRange to hasUnresolvableRange and also detect open-ended ranges; bypass when object size is unknown - internal.go: add nil check for rng before accessing rng.End - multirange: use rangecontrol.Parse for proper range detection; single suffix ranges pass through to next layer; return 416 for truly unresolvable ranges (unknown objSize without Content-Range) - Add benchmark tests for Parse, ParseRange, and ContentRange Co-Authored-By: Claude <noreply@anthropic.com>

sendya · 2026-07-06T14:47:16Z

概述

修复 issue #63 — 客户端发送 suffix range（如 Range: bytes=-512）时的两个 bug：

multirange 中间件错误拒绝 suffix range：原有代码对所有 rangecontrol.Parse 失败都返回 416，但 suffix range 是 RFC 7233 合法的 HTTP Range 格式，multirange 不应拦截单 suffix range。
fillRange 将 suffix range 计算为 MaxInt64 无效范围：未知对象大小时用 math.MaxInt64 推导 suffix range 起始位置，导致生成天文数字的 Range 头发送到上游。

修改内容

P0: multirange 透传单 suffix range

使用 rangecontrol.Parse(rawRange, math.MaxInt32) 替代自定义 hasSuffixRange
单 range（含 suffix range）透传到下一层
无效 range（如 bytes=abc, bytes=-）返回 416
混合 suffix multi-range（如 bytes=0-99,-512）在未知对象大小时拒绝

P0: fillRange 绕过不可解析 range

hasSuffixRange → hasUnresolvableRange，同时检测 suffix range 和 open-ended range
未知对象大小时绕过，避免 MaxInt64 计算

P0: rangecontrol.Parse 支持 totalSize

接受 totalSize 参数以解析 suffix range
suffix range 超过对象大小时跳过（而非生成负数 start）

其他

internal.go: 新增 rng nil 检查防止 panic
新增 benchmark 测试

边界情况

场景	修复前	修复后
`bytes=-512` cache MISS	MaxInt64 无效范围	透传到上游
`bytes=-512` cache HIT	416	使用已知 Size 正确返回
`bytes= -512`	可能异常	识别为 suffix range 透传
`bytes=0-99,-512`	可能被错误处理	未知大小时 416
`bytes=100-` cache MISS	MaxInt64 无效范围	透传到上游
`bytes=abc`	416	保持 416

Closes#63

🤖 Generated with Claude Code

… middleware

- rangecontrol.Parse now accepts totalSize to resolve suffix ranges and open-ended ranges; skips suffix ranges exceeding total size - fillRange: rename hasSuffixRange to hasUnresolvableRange and also detect open-ended ranges; bypass when object size is unknown - internal.go: add nil check for rng before accessing rng.End - multirange: use rangecontrol.Parse for proper range detection; single suffix ranges pass through to next layer; return 416 for truly unresolvable ranges (unknown objSize without Content-Range) - Add benchmark tests for Parse, ParseRange, and ContentRange Co-Authored-By: Claude <noreply@anthropic.com>

sendya · 2026-07-06T14:47:16Z

概述

修复 issue #63 — 客户端发送 suffix range（如 Range: bytes=-512）时的两个 bug：

multirange 中间件错误拒绝 suffix range：原有代码对所有 rangecontrol.Parse 失败都返回 416，但 suffix range 是 RFC 7233 合法的 HTTP Range 格式，multirange 不应拦截单 suffix range。
fillRange 将 suffix range 计算为 MaxInt64 无效范围：未知对象大小时用 math.MaxInt64 推导 suffix range 起始位置，导致生成天文数字的 Range 头发送到上游。

修改内容

P0: multirange 透传单 suffix range

使用 rangecontrol.Parse(rawRange, math.MaxInt32) 替代自定义 hasSuffixRange
单 range（含 suffix range）透传到下一层
无效 range（如 bytes=abc, bytes=-）返回 416
混合 suffix multi-range（如 bytes=0-99,-512）在未知对象大小时拒绝

P0: fillRange 绕过不可解析 range

hasSuffixRange → hasUnresolvableRange，同时检测 suffix range 和 open-ended range
未知对象大小时绕过，避免 MaxInt64 计算

P0: rangecontrol.Parse 支持 totalSize

接受 totalSize 参数以解析 suffix range
suffix range 超过对象大小时跳过（而非生成负数 start）

其他

internal.go: 新增 rng nil 检查防止 panic
新增 benchmark 测试

边界情况

场景	修复前	修复后
`bytes=-512` cache MISS	MaxInt64 无效范围	透传到上游
`bytes=-512` cache HIT	416	使用已知 Size 正确返回
`bytes= -512`	可能异常	识别为 suffix range 透传
`bytes=0-99,-512`	可能被错误处理	未知大小时 416
`bytes=100-` cache MISS	MaxInt64 无效范围	透传到上游
`bytes=abc`	416	保持 416

Closes#63

🤖 Generated with Claude Code

… middleware

- rangecontrol.Parse now accepts totalSize to resolve suffix ranges and open-ended ranges; skips suffix ranges exceeding total size - fillRange: rename hasSuffixRange to hasUnresolvableRange and also detect open-ended ranges; bypass when object size is unknown - internal.go: add nil check for rng before accessing rng.End - multirange: use rangecontrol.Parse for proper range detection; single suffix ranges pass through to next layer; return 416 for truly unresolvable ranges (unknown objSize without Content-Range) - Add benchmark tests for Parse, ParseRange, and ContentRange Co-Authored-By: Claude <noreply@anthropic.com>

sendya · 2026-07-06T14:47:16Z

概述

修复 issue #63 — 客户端发送 suffix range（如 Range: bytes=-512）时的两个 bug：

multirange 中间件错误拒绝 suffix range：原有代码对所有 rangecontrol.Parse 失败都返回 416，但 suffix range 是 RFC 7233 合法的 HTTP Range 格式，multirange 不应拦截单 suffix range。
fillRange 将 suffix range 计算为 MaxInt64 无效范围：未知对象大小时用 math.MaxInt64 推导 suffix range 起始位置，导致生成天文数字的 Range 头发送到上游。

修改内容

P0: multirange 透传单 suffix range

使用 rangecontrol.Parse(rawRange, math.MaxInt32) 替代自定义 hasSuffixRange
单 range（含 suffix range）透传到下一层
无效 range（如 bytes=abc, bytes=-）返回 416
混合 suffix multi-range（如 bytes=0-99,-512）在未知对象大小时拒绝

P0: fillRange 绕过不可解析 range

hasSuffixRange → hasUnresolvableRange，同时检测 suffix range 和 open-ended range
未知对象大小时绕过，避免 MaxInt64 计算

P0: rangecontrol.Parse 支持 totalSize

接受 totalSize 参数以解析 suffix range
suffix range 超过对象大小时跳过（而非生成负数 start）

其他

internal.go: 新增 rng nil 检查防止 panic
新增 benchmark 测试

边界情况

场景	修复前	修复后
`bytes=-512` cache MISS	MaxInt64 无效范围	透传到上游
`bytes=-512` cache HIT	416	使用已知 Size 正确返回
`bytes= -512`	可能异常	识别为 suffix range 透传
`bytes=0-99,-512`	可能被错误处理	未知大小时 416
`bytes=100-` cache MISS	MaxInt64 无效范围	透传到上游
`bytes=abc`	416	保持 416

Closes#63

🤖 Generated with Claude Code

… middleware

- rangecontrol.Parse now accepts totalSize to resolve suffix ranges and open-ended ranges; skips suffix ranges exceeding total size - fillRange: rename hasSuffixRange to hasUnresolvableRange and also detect open-ended ranges; bypass when object size is unknown - internal.go: add nil check for rng before accessing rng.End - multirange: use rangecontrol.Parse for proper range detection; single suffix ranges pass through to next layer; return 416 for truly unresolvable ranges (unknown objSize without Content-Range) - Add benchmark tests for Parse, ParseRange, and ContentRange Co-Authored-By: Claude <noreply@anthropic.com>

sendyaand others added 3 commits July 2, 2026 00:14