摘要

  • RFC 3648 把排序定义为集合状态，但同一父集合内的 MOVE 可以保留原位置，也可以按“删除后新增”处理；后者在没有 Position 时会追加到末尾。
  • 可审计的控制器必须连接完整前态、能力与权限、原始请求、响应、Depth: 1 PROPFIND 后态和最终展示，不能用 2xx 代替这条证据链。

RFC 3648 先划清了“有序”与“无序”。无序集合不保证两次 PROPFIND 的枚举顺序一致。有序集合必须按照其顺序返回成员；每个内部成员恰好出现一次，非成员不得混入。删除成员不会改变剩余成员的相对位置，新增成员则进入排序状态。

真正考验自动化的是同父 MOVE。纯文本规范 允许服务器把它实现成单纯改名，从而保留位置；也允许先删除再新增。新增规则规定，缺少 Position 时放到末尾。规范还说，未来可在获得实现经验后缩小差异。这说明两种结果都是规范边界，而不是任何具体服务器已经如此运行的证据。

排序属于集合，不属于某个临时请求。一个集合只有一种顺序；同一批资源需要多种顺序时，应由多个集合表达。同一集合资源即使通过不同 URI 访问，顺序也相同，并受集合锁和访问控制约束。RFC 5842 讨论多绑定，有助于区分“一个资源有多个访问 URI”与“多个集合各自持有状态”。

受保护属性 DAV:ordering-type 表示排序语义。DAV:unordered 明确否认可重复顺序；DAV:custom 只说顺序存在，并不承诺跨应用的共同含义。排序类型也可由 URI 标识，但安全章节警告客户端不要自动解引用它，否则大量客户端可能被引向攻击目标。这个 URI 是含义标识，不是执行地址。

Position 可表达 first、last、before、after，目前仍列在 IANA HTTP 字段注册表 中。它能缩小 MOVE 的实现差异，却不能单独证明结果。参照 segment 必须仍是该集合成员且不能等于被移动成员；集合必须有序；锁与权限也必须满足。RFC 3744 提供访问控制语义，知道成员名称不等于拥有改序权。

ORDERPATCH 的原子性同样不能被夸大。服务器按文档次序处理 order-member，必须全部应用或全部不应用，失败时恢复前态。这是单次服务器操作的全有或全无，不是缓存、索引、导航组件与用户看到同一结果的证明。如果请求改变排序语义却省略部分成员，明确列出的成员在前，未列成员的相对顺序由服务器决定。成功请求也可能留下规范允许的不确定尾部。

最直接的协议读回是 Depth: 1 PROPFIND。Depth: infinity 可能把不同层级的后代穿插返回，只保证各有序集合内部的局部顺序，并非一张全局平表。RFC 2518 是 RFC 3648 所依赖的早期 WebDAV 基础，后来由 RFC 4918 取代；它们都不会让状态码变成界面顺序证明。

版本化还存在一条边界。RFC 3253 定义 DeltaV。RFC 3648 可在集合版本中记录排序类型和受版本控制成员的顺序，并在 UPDATE 或 MERGE 中恢复；未受版本控制成员的位置仍由服务器决定。因此“版本恢复成功”也不能推出全部可见成员都回到唯一位置。

有序集合能力是可选项，需要通过 OPTIONS、ordered-collections 符合性类、Allow 和受支持属性逐资源发现。父集合支持不证明子集合支持。RFC 5689 扩展 MKCOL 请求体，但能提交扩展属性不等于服务器接受了所请求的排序语义。

RFC 7232 与 RFC 9110 的条件请求和验证器可以被具体部署用于并发控制，但 RFC 3648 没有定义专用的排序版本号或状态摘要。若某产品暴露有效验证器，证据必须把它记录为实现事实，不能倒写成 RFC 保证。

before/after 的 segment 词汇来自 RFC 2396，一般 URI 语法后来由 RFC 3986 更新。segment 是针对当前成员快照的定位操作数，不是永久身份、授权凭据或未来存在承诺。

规范沿革可从 Datatracker、RFC Editor 信息页、历史记录和勘误页核验。这些页面证明文本来历，不提供部署遥测。

用 Heng Lu 的运行代码优先、最小初始规范与现实层来审视，边界很清楚：标准给出共同的最小协调面，运行代码从允许选项中作出选择，读回证明服务器暴露了什么，展示和人的接收又是后续层。任何一层都不能借上一层的绿色状态冒充完成。

控制器应保存：集合身份与访问 URI、排序类型、完整前序列、能力发现、锁与授权判定、MOVE 或 ORDERPATCH 原始字节、Position 与参照 segment、响应、完整 Depth: 1 后序列、实际可用的版本或验证器，以及消费端展示顺序。缺失的箭头应当显示为未知，而不是由 2xx 自动补齐。