curl支持webdav但默认禁用patch、propfind等方法，需编译时启用libxml2；上传必须用put并显式设置curlopt_customrequest，配合curlopt_upload和正确content-type，注意认证、url编码及服务端差异。
curl 支持 WebDAV 方法但默认禁用 PATCH、PROPFIND 等
标准 curl 命令行工具本身支持 WebDAV，但多数发行版编译时没启用 --with-libxml2 或 --with-nghttp2，导致 PROPFIND、PROPPATCH 等方法无法正常解析 XML 响应体。常见现象是返回 405 Method Not Allowed，或响应体为空却状态码为 207（Multi-Status）。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 先验证本地
curl是否支持：curl --version | grep -i "libxml\|http2"；若无输出，优先换用系统包管理器安装带完整依赖的版本（如 Ubuntu 的curl包通常已含 libxml2） - 上传文件必须用
PUT，不是POST—— WebDAV 规范中PUT才代表资源创建/覆盖，POST语义不明确且服务端通常拒绝 -
PUT请求需显式设置Content-Type，即使二进制文件也建议设为application/octet-stream，否则某些服务端（如 Apache mod_dav）会拒收
C++ 用 libcurl 发起 WebDAV PUT 时必须手动注册 HTTP 扩展方法
libcurl 默认只认 GET、POST、HEAD 等 RFC 2616 标准方法，PUT 虽被支持，但需主动告诉它“这是合法方法”，否则会静默降级为 POST 或报错 CURLE_UNKNOWN_OPTION。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 调用
curl_easy_setopt(handle, CURLOPT_CUSTOMREQUEST, "PUT")是最稳妥方式，不要依赖CURLOPT_PUT（该选项已废弃且仅支持旧式文件上传） - 必须设置
CURLOPT_UPLOAD为1L，否则 libcurl 不会进入上传模式，PUT请求体为空 - 用
CURLOPT_READFUNCTION+CURLOPT_READDATA控制数据源，避免把整个文件读入内存；尤其大文件场景下，直接fread流式读取更安全 - 务必检查服务端是否要求认证：WebDAV 多数部署在 Basic Auth 或 Digest Auth 下，漏掉
CURLOPT_HTTPAUTH和CURLOPT_USERPWD会导致 401 并可能触发重定向循环
WebDAV 上传失败常见错误码与对应动作
不同于普通 HTTP API，WebDAV 错误码含义更具体，光看状态码不够，得结合响应头和 body 分析。
常见错误现象与应对：
-
409 Conflict：目标路径存在同名集合（目录），但请求试图上传文件。需先PROPFIND检查父路径是否存在，或改用MKCOL创建中间目录 -
423 Locked：资源被锁（Lock-Token头缺失或过期）。除非业务明确需要加锁，否则上传前不要发LOCK请求；若必须加锁，注意锁令牌有效期和作用域 -
422 Unprocessable Entity：XML 请求体格式错误（比如PROPPATCH中 property 名非法）。上传文件一般不涉及此码，但若后续要设属性，需严格校验命名空间和标签嵌套 -
507 Insufficient Storage：服务端磁盘满。此时重试无意义，应记录并告警，而非指数退避
别忽略 WebDAV 的 URL 编码与路径语义差异
WebDAV 对路径中空格、中文、斜杠的处理比普通 HTTP 更敏感。服务端实现（如 Nextcloud、Apache、IIS）对编码规则的支持程度不一，同一 URL 在不同后端表现可能完全不同。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 所有路径组件（包括文件名）必须用
curl_easy_escape()编码，不能只靠std::filesystem::path::string()直接拼接 - 结尾斜杠有语义：带斜杠表示集合（目录），不带表示资源（文件）。上传文件时 URL 绝对不能以
/结尾，否则部分服务端会当成创建空目录 - 避免在 URL 中使用
%2F（编码后的斜杠）——多数 WebDAV 服务端不支持路径内编码斜杠，会直接 400，应确保原始路径是扁平的（即不传嵌套路径，而用多级MKCOL构建）
WebDAV 的坑不在协议本身，而在服务端实现碎片化。同一个 PUT 请求，在 Apache 上成功，在 Nextcloud 上 403，在某私有网盘上 500，几乎是常态。调试时优先抓包看原始请求头和响应头，别只信 curl 的 verbose 输出。
