curl 加上 --path-as-is 后仍未发送 URL 的 #fragment

把 URL 写成 http://127.0.0.1:8080/index.html#section，已经加上引号和 --path-as-is，详细输出中的请求目标却只有 /index.html。如果正在检查本机 HTTP 服务如何处理特殊请求目标，这会让测试内容与预期不一致。

#section 属于 URL 的片段标识符，不属于正常 HTTP 请求发送给服务器的路径。curl 会移除这一部分。--path-as-is 只控制路径中 /./、/../ 这类序列的归并，不表示原封不动地发送整个 URL。

本文的原始请求目标示例限于自建的本机测试服务。普通业务请求应遵循 URL 编码及接口约定，不需要为了“保留地址”而发送不符合常规 URL 形式的目标。

引号与 path-as-is 解决不了片段语义

假设本机已有允许调试的 HTTP 服务，以下命令用于观察正常解析后的请求：

curl --http1.1 --verbose --path-as-is \
  'http://127.0.0.1:8080/index.html#section'

按 URL 规则，请求行里的目标应为 /index.html。引号保证 shell 把完整地址作为一个参数交给 curl，却不改变 curl 对 URL 的解析。继续给井号增加 shell 转义，不能把片段标识符变成正常路径的一部分。

--path-as-is 自 curl 7.42.0 起提供，--request-target 自 7.55.0 起提供。先检查 curl --version；不要把某个选项不受支持与片段被正常移除混为一个问题。

如果业务含义是“路径名称本身包含 #”，应在对应数据位置使用 %23，例如：

curl --http1.1 --verbose \
  'http://127.0.0.1:8080/files/report%23draft.txt'

这条 URL 的路径不再带有未编码的片段分隔符。服务器如何解码并映射这个路径，仍由应用和路由配置决定；发送了 %23 不保证目标文件或路由一定存在。

不要把真正用于网页内定位的 #section 一律改成 %23section。前者是本地片段语义，后者改变了服务器接收的路径数据，会请求不同资源。也不要对已经编码的 %23 再做一次编码，变成另一个值。

若目的就是让本机测试服务接收一个含裸井号的原始 HTTP 请求目标，可以将连接 URL 与请求目标分开：

curl --http1.1 --verbose \
  --request-target '/index.html#section' \
  'http://127.0.0.1:8080/'

连接地址仍然是 127.0.0.1:8080，目标参数替换的是 HTTP 请求中的目标部分。使用 HTTP/1.1 是为了能直接观察文本请求行。预期发送的请求行是：

GET /index.html#section HTTP/1.1

--request-target 会按给定内容传递目标，不替输入做常规 URL 过滤。这里只传入固定的演示字符串；不要把未经验证的外部输入直接拼到该参数里，更不要加入换行或控制字符。它也不是普通 API 参数编码的替代品。

收到 400 等错误响应并不表示 curl 又把片段丢掉了。这个测试本来就在使用非常规目标，服务可以拒绝它。判断发送是否符合预期，应查看 curl 的请求行与自己控制的服务接收记录，而不是要求响应必须为 200。

在测试服务的日志中对照三个请求：正常 URL 片段应在客户端移除，编码后的 %23 属于路径数据，显式目标则按给定字符串发送。服务日志可能会解码或重新格式化路径，因此需要了解日志字段记录的是原始目标还是解析后的路径，不能只凭页面最终显示内容判断。

详细输出和服务日志可能包含其他请求头及敏感信息。示例不需要认证、Cookie 或真实业务参数；如迁移到自己的测试环境，先去除这些内容，验证后关闭临时详细输出。

结束特殊目标测试后移除 --request-target，让正常调用恢复从 URL 生成请求目标。若某个业务参数原本就在错误的位置，应按接口约定改到路径或查询数据中；调整这次 curl 命令不会修复服务端不存在的路由，也不会撤销已经处理过的请求。