SOAP with Attachments (SwA) 是什么

SOAP with Attachments（SwA）是一种用MIME multipart/related包装SOAP消息与二进制附件的约定，避免Base64编码导致的体积膨胀和解析开销，但因互操作性差、生态支持弱，已被MTOM和REST替代。

SOAP with Attachments（SwA）不是新协议，而是一种**用标准 MIME 多部分（multipart/related）包装 SOAP 消息 + 二进制附件的约定**。它把 xml 的 Envelope 当作一个 part，把图片、pdf、ZIP 等原始二进制文件当作其他 parts，再用 Content-ID 和 href="cid:xxx" 在 SOAP Body 里引用它们。 它解决的核心问题是：**不把二进制数据 Base64 编进 XML 字符串里**——避免体积膨胀约 33%、解析开销大、XML 工具链难处理等问题。 但 SwA 已基本被弃用。下面说清楚怎么用、为什么现在不该用、以及你真正该关心什么。

SwA 的 http 请求长什么样？

关键点是：Content-Type: multipart/related + start 参数指向 SOAP part，每个 part 有独立 Content-ID：

POST /service HTTP/1.1 Content-Type: multipart/related; type="text/xml"; start="" Content-Length: ...  --boundary_123 Content-ID:  Content-Type: text/xml                             --boundary_123 Content-ID:  Content-Type: application/pdf  %PDF-1.4...（原始 PDF 二进制字节，无编码）

• start 必须匹配第一个 part 的 Content-ID（含尖括号）
• href="cid:xxx" 中的 xxx 必须与目标 part 的 Content-ID 值严格一致（包括尖括号）
• 附件内容**不能做 Base64 编码**——这是 SwA 相比纯 XML Base64 的最大优势
• 多数现代 HTTP 客户端（如 python requests、node.js node-fetch）默认不生成这种结构，需手动构造 multipart body

为什么 SwA 几乎没人用了？

不是它设计得不好，而是生态和规范演进淘汰了它：

• .net Framework 2.0+ 完全不支持 SwA，只支持 MTOM；java Axis2 默认关掉 SwA，需显式启用且易出错
• WSDL 1.1 的 document/literal 绑定与 SwA 不兼容——而 document/literal 已成事实标准
• SwA 没定义如何处理多个附件、附件元数据、错误时的附件清理等边界问题，各实现五花八门
• W3C 正式推荐 MTOM（基于 XOP）替代 SwA，它保留了“不 Base64 编码”的核心优势，但通过标准化的 xop:include 元素 + 更健壮的 MIME 规则解决了互操作性问题

你今天该用什么？MTOM 还是直接绕过 SOAP？

除非对接遗留系统明确要求 SwA，否则不要主动选它：

• 新服务优先用 MTOM：主流框架（Java CXF/JAX-WS、.NET WCF、Python Zeep）都原生支持，WSDL 可自动生成，Content-Transfer-Encoding: binary + xop:Include 更可靠
• 如果只是传文件，考虑放弃 SOAP 全流程：用 REST + multipart/form-data（如 curl -F "file=@report.pdf" https://api.example.com/upload），更轻量、调试直观、工具链成熟
• 若必须用 SwA（比如老 IBM DataPower 或 WebSphere 配置），注意：HTTP 节点需开启 MIME 解析，且不能用通用 XML 解析器直接读 Body——必须先按 multipart/related 拆包，再分别处理 XML part 和附件 part

SwA 是 Web 服务早期对二进制传输的一次务实尝试，但它把 MIME 边界、引用语义、错误恢复这些本该由协议层管的事，丢给了应用层去拼凑。现在回头看，它的“简单”恰恰成了最大的兼容性陷阱。