通过带有 MTOM 和 Content-Transfer-Encoding 的 WCF 发送 SOAP 消息：7 位答案

【问题标题】：Send SOAP messages via WCF with MTOM and Content-Transfer-Encoding: 7-bit通过带有 MTOM 和 Content-Transfer-Encoding 的 WCF 发送 SOAP 消息：7 位
【发布时间】：2016-01-27 15:04:43
【问题描述】：

我正在尝试通过 WCF 向 IRS 发送 SOAP 消息，但由于我的 MTOM 附件格式不正确，它一直被拒绝。

我已将问题范围缩小到我的 Content-Transfer-Encoding 值。它设置为Binary（8-bit 的简写）。

IRS 服务希望我使用带有 8 位编码附件的 7-bit（换句话说，使用 UTF-8 编码，然后保证我没有使用任何非 ASCII 字符）。

我已经在使用自定义消息编码器来压缩我的请求（回复以纯文本形式返回，呃）。这就是我的WriteMessage 现在的样子。

public override ArraySegment<byte> WriteMessage(Message message, int maxMessageSize, BufferManager bufferManager, int messageOffset) {
    // get an instance of the underlying encoder
    var encoder = new MtomMessageEncodingBindingElement() {
            MessageVersion = MessageVersion.Soap11WSAddressing10,
            WriteEncoding = System.Text.Encoding.UTF8
        }.CreateMessageEncoderFactory().Encoder;

    // write the message contents
    var uncompressed = encoder.WriteMessage(message, maxMessageSize, bufferManager, messageOffset);

    // compresses the resulting byte array
    return CompressBuffer(uncompressed, bufferManager, messageOffset);
}

有什么想法吗？当我将 WriteEncoding 属性更改为 ASCII 或 UTF7 时，.NET 会抛出 ArgumentException 并告诉我该格式不受支持。

【问题讨论】：

经过更多研究后，我认为 8 位编码问题比 MTOM 尝试对 WSS 安全标头进行编码（这会导致证书优化为MTOM 附件）。这是由 WCF 完成的，我无法控制，所以我正在考虑编写一个自定义消息编码器来克服它。希望这里有人可以给我一个更好的答案，如果它存在的话，在我走得太远之前:)

标签： wcf soap mtom 7-bit irs

【解决方案1】：

WCF 中的内置 MTOM 编码器似乎不会对与 IRS 服务兼容的请求进行编码。它对它在请求中找到的任何内容进行编码，这些请求是 base64 编码的，包括签名请求中的 BinarySecurityToken。通过创建自定义编码器，我能够获得更接近 IRS 要求的请求。在 WriteMessage 中，您可以附加和前置 MIME 分隔符，并将文件重新编码为附件。需要外发消息检查器才能正确设置标头：https://blogs.msdn.microsoft.com/carlosfigueira/2011/04/18/wcf-extensibility-message-inspectors/

【讨论】：

我相信你是对的。我采取了一种稍微不同的方法，只是颠倒了我不想要的 MTOM 编码结果的部分。我目前仍在努力让请求被接受，但 IRS 无法使用我的原始请求重现我现在收到的错误。我今天与他们安排了一个电话，以找出问题所在（希望如此）。谢谢你插话！如果我使用的当前解决方案不起作用，我会尝试您的方法。
很想知道您是否使用 C# 进行了这项工作。我非常接近自定义 mtom 编码方法，但现在在他们解析请求时收到错误消息：TPE1106 发现以元素“签名”开头的无效内容。此时不需要子元素...由于唯一的签名元素在安全令牌中并且安全性已经过验证，我假设 IRS 开始通过信封头解析。可能是因为 .NET 安全标头没有 wsse 命名空间，所以会抛出此错误。
我让 MTOM 工作（必须真正破解 WCF 才能让它工作），现在我的安全标头无效，因为我在 MTOM 编码后对消息做了什么。我将在我（重新）实施手动签名消息后的几个小时内报告。
似乎整个 .Net 社区大约在同一时间开始融合这些解决方案。看到这些更新非常有趣:)

【解决方案2】：

我在 IRS 解决方案中使用 Java Apache CXF 和 WSS4J，但如果您收到此错误“消息格式不正确和/或无法解释。请查看 AIR 提交的第 3 节中概述的 XML 标准作文和参考指南位于https://www.irs.gov/for-Tax-Pros/Software-Developers/Information-Returns/Affordable-Care-Act-Information-Return-AIR-Program，请更正任何问题，然后重试。”这是因为美国国税局期待这一点：

Content-Type: application/xml
Content-Transfer-Encoding: 7bit
Content-ID: <6920edd2-a3c7-463b-b336-323a422041d4-1@blahurn:us:gov:treasury:irs:common>
Content-Disposition: attachment;name="1094B_Request_BBBBB_20151019T121002000Z.xml"

【讨论】：

在我们通过 .NET 和 WCF 完成之后，这可能是迄今为止更简单的方法。我听说使用 Java 的人在签名时遇到问题，但很可能他们只是不了解 SOAP 安全性。