Go url.ParseRequestURI 处理请求目标的边界

如果手里的字符串来自 HTTP 请求行，url.ParseRequestURI 比通用的 url.Parse 更贴近输入语义：它只把内容当作绝对 URI 或绝对路径处理，并允许请求目标专用的 *。我在网关和代理代码里迁移这类解析时，最容易踩的坑不是“解析失败”，而是把“解析成功”误当成“业务允许”。

官方定义可直接查看：https://pkg.go.dev/net/url#ParseRequestURI。

升级范围：它处理的是请求目标，不是任意 URL

url.Parse 接受的输入更宽，适合解析一般 URL 或相对引用；url.ParseRequestURI 面向 HTTP 请求中的 request-target。它内部以请求语境解析，因此没有 scheme 且不以斜杠开头的字符串会被判为非法请求 URI。

在普通 Go HTTP 服务端，http.Request 已经根据请求行填好了 r.URL。业务处理器通常应直接使用 r.URL.Path 和 r.URL.Query()，不要无理由再次解析 r.RequestURI。只有网关、协议适配器、原始报文解析器或针对 request-target 的测试工具，才常常需要直接调用这个函数。

变更表：ParseRequestURI 接受什么

这里最反直觉的是 //example.com/orders：在通用 URL 语境里它看起来像 scheme-relative URL，但在请求目标语境里会作为路径保存，Host 不会因此被填充。需要主机信息时，应按协议形态从绝对 URI 或 HTTP Host 字段中取得，不要仅凭字符串前缀猜测。

旧代码风险：宽松解析和手工拆分会隐藏输入差异

旧代码常见两种做法：一是用 url.Parse 接住所有字符串，二是先按问号手工切分路径和查询串。前者可能让相对引用悄悄通过，后者容易破坏百分号转义、重复查询参数和空值语义。迁移后应让标准库先完成语法解析，再根据业务接受的请求形式做显式限制。

raw := "/orders/42?view=full"

u, err := url.ParseRequestURI(raw)
if err != nil {
    // 语法错误应在协议入口直接返回，避免进入路由层。
    return fmt.Errorf("解析请求目标: %w", err)
}

fmt.Println(u.Path)     // /orders/42
fmt.Println(u.RawQuery) // view=full

空字符串、控制字符、错误的百分号转义和格式不完整的绝对 URI 都应按错误处理。片段标识符也不属于 HTTP 请求目标：浏览器通常不会把 fragment 发送到服务器，因此不要设计依赖 #fragment 的服务端路由。

新写法：语法解析后再叠加策略

假设内部服务只接受以斜杠开头的 origin-form，请把这个约束写成解析后的独立策略。下面的包装函数拒绝 absolute-form、空路径、双斜杠开头和星号形式；这些不是 ParseRequestURI 自带的承诺，而是示例服务自己的入口合同。

package target

import (
    "errors"
    "fmt"
    "net/url"
    "strings"
)

type OriginTarget struct {
    Path        string
    EscapedPath string
    Query       url.Values
}

func ParseOriginTarget(raw string) (OriginTarget, error) {
    u, err := url.ParseRequestURI(raw)
    if err != nil {
        // 第一层只负责报告 request-target 的语法错误。
        return OriginTarget{}, fmt.Errorf("解析请求目标: %w", err)
    }

    // 本服务只接受 origin-form，不接收 absolute-form。
    if u.IsAbs() || u.Host != "" {
        return OriginTarget{}, errors.New("只接受 origin-form 请求目标")
    }
    // 星号和双斜杠路径需要单独策略，避免被普通路由误收。
    if u.Path == "*" || !strings.HasPrefix(u.Path, "/") || strings.HasPrefix(u.Path, "//") {
        return OriginTarget{}, errors.New("请求目标不在允许范围")
    }

    return OriginTarget{
        Path:        u.Path,
        EscapedPath: u.EscapedPath(),
        Query:       u.Query(),
    }, nil
}

这层检查仍然不是完整的安全方案。主机白名单、代理信任边界、路由允许列表、租户隔离和文件路径授权必须由对应层处理。尤其不要因为 ParseRequestURI 返回了 nil 错误，就直接把路径拼进文件系统或转发到任意上游。

回归检查：Path 与 EscapedPath 要一起测

Path 是解码后的路径，RawPath 只在需要保存默认转义形式时作为提示；需要得到可发送的转义路径时使用 EscapedPath()。如果路由或授权规则需要区分编码斜杠，就必须明确使用哪一种表示，并在所有层保持一致。

func TestParseOriginTarget(t *testing.T) {
    tests := []struct {
        name    string
        raw     string
        wantErr bool
    }{
        {name: "带查询串的绝对路径", raw: "/orders/42?view=full"},
        {name: "编码斜杠", raw: "/files/a%2Fb"},
        {name: "相对路径", raw: "orders/42", wantErr: true},
        {name: "绝对 URI", raw: "https://example.com/orders", wantErr: true},
        {name: "双斜杠路径", raw: "//example.com/orders", wantErr: true},
        {name: "星号形式", raw: "*", wantErr: true},
        {name: "错误转义", raw: "/files/%zz", wantErr: true},
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            // 每个边界输入都同时覆盖解析层与本服务策略层。
            _, err := ParseOriginTarget(tt.raw)
            if (err != nil) != tt.wantErr {
                t.Fatalf("ParseOriginTarget(%q) error=%v, wantErr=%v", tt.raw, err, tt.wantErr)
            }
        })
    }
}

迁移清单

• 确认输入确实来自 HTTP request-target，而不是用户粘贴的普通 URL 或相对链接。
• 列出服务允许的形态：origin-form、absolute-form、authority-form 或星号形式，不要默认全部接收。
• 删除手工按问号切分的逻辑，使用 Path、RawQuery 和 Query()。
• 为 // 开头、*、空串、控制字符、错误转义和绝对 URI 增加回归用例。
• 明确授权和路由使用解码后的 Path 还是 EscapedPath()。
• 在标准 net/http 处理器中优先使用已经解析好的 r.URL。

相关问题

ParseRequestURI 和 url.Parse 的主要区别是什么？

ParseRequestURI 按 HTTP 请求目标语境收紧输入；url.Parse 更通用，也能解析相对引用。选择哪一个取决于字符串的来源和协议角色。

为什么 //example.com/a 没有得到 Host？

请求语境中，没有 scheme 且以斜杠开头的输入按绝对路径处理，因此这段内容落在 Path，不会自动解释成 scheme-relative authority。

解析成功是否代表路径安全？

不是。解析成功只说明语法被接受；目录穿越防护、路由允许列表、主机校验和访问授权仍需独立实现。