Postman发multipart/related MTOM SOAP请求报Unexpected EOF in prolog

错误本质 #

报错Unexpected EOF in prolog at [row,col {unknown-source}]: [1,0]说明服务端SOAP解析器根本没有读取到合法的XML内容流，在请求流的第1行第0个字符位置就遇到了流结束标记，核心诱因是请求的multipart格式不符合规范、传输层配置冲突、解析边界不匹配。

定位到的具体问题点 #

• 缺失multipart分段的强制空行：RFC 2046规范要求每个multipart分段必须满足「分段头部行集合 + 空行 + 分段实际内容」的结构，当前提交的payload里，分段头部写完直接接XML内容，没有空行分隔，解析器会把第一个分段的边界、头部行全部当成XML内容读取，直接判定根分段无合法XML内容。
• 手动指定传输编码冲突：请求头里手动添加了Transfer-Encoding: chunked，但Postman实际发送时会自动计算固定长度的Content-Length头，两个传输规则冲突会导致传输层提前截断请求流，服务端读到一半就收到EOF。
• 头部格式不规范：第二个分段的Content-Id行冒号后缺失空格、第二个分段的Content-Type行末尾带多余空格，Oracle JAX-WS的严格解析器会识别失败，直接丢弃整个分段内容。
• 手动配置的请求头参数和实际payload不匹配：手动写的Content-Type里带了boundary、start定位参数，没有和实际payload里的边界串、Content-Id完全对齐，服务端找不到根SOAP分段的起始位置，读到的流开头是空的。
• XML绑定错误：SOAP Body里的submitLargeDocument方法错绑定到了wsa命名空间，实际应该绑定业务接口的tns命名空间，就算流解析通过也会触发方法找不到的二次报错。

可直接落地的修复方案 #

1. 删掉所有手动添加的Transfer-Encoding: chunked请求头，交由Postman自动处理传输层编码逻辑，避免和自动生成的Content-Length冲突。
2. 严格按照规范调整payload格式，确保：
   • 每个分段的所有头部写完后，插入一个单独的空行（两个连续换行）再放实际分段内容
   • 最后结束的边界串--[你的边界值]--后面必须加一个换行，不能直接以这个字符串作为请求流的结尾
   • 所有Content-Id行严格使用Content-Id: <对应ID串@example.com>格式，冒号后加空格
3. 简化Content-Type请求头配置，只保留基础的multipart/related类型，去掉手动硬编码的boundary、start、type参数，由Postman自动匹配payload里的实际边界值，避免参数不匹配导致的分段定位失败。
4. 修正SOAP XML的命名空间绑定，把submitLargeDocument、Document元素的命名空间从wsa调整为对应的业务tns命名空间，xop:Include元素替换为正确的xop命名空间引用。
5. 调整完成后，优先用Postman内置的表单构造功能生成multipart/related请求，不要手动粘贴复杂的multipart raw内容——Postman自动构造的格式会严格匹配RFC规范，从根源避免换行、边界格式的低级问题。

内容的提问来源于stack exchange，提问作者Pavan Elthepu