WcfCoreMtomEncoder icon indicating copy to clipboard operation
WcfCoreMtomEncoder copied to clipboard

Handle missing Content headers

Open bcallaghan-et opened this issue 4 years ago • 1 comments

While using your library, I noticed that several of my SOAP messages do not specify Content-Id or Content-Transfer-Encoding for the XML part of the multipart message. This caused an ArgumentNullException when attempting to match those headers against the Regex found in MtomMessageEncoder and MtomPart.

I attempted to fix this myself by changing the fallbacks in MtomPart from null to 8bit and String.Empty respectively. This resolved my issue. Are there any downsides to this solution? Would you like me to submit a PR?

Maybe unrelated, but the same messages also use domain names as part of their content IDs. For example:

<ImageData>
  <xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:7bc0e65d-2fea-4e90-a6e6-bd77eee209c9%40www.mydomain.com"/>
</ImageData>

You'll notice that the @ symbol was URL-encoded to %40, but it was not URL-encoded in the Content-Id header. I was able to resolve this by URL-decoding the XML href attribute before comparing the two values. Again, are there any downsides to this solution?

bcallaghan-et avatar Apr 28 '20 23:04 bcallaghan-et

I found another issue, which I think I can fix. One of my XML messages contained an illegal control character &#26; inside the text of an element. This caused an exception within MtomMessageEncoder. I am not in control of the SOAP service or its data, so I'm forced to accept this illegal character. I solved this by wrapping the XML string with an XmlReader that was configured with CheckCharacters = false. I then loaded that reader into an XDocument. Similarly, I had to add an XmlWriter to avoid the same exception when saving the updated XML string. Are there any dangers to this approach?

bcallaghan-et avatar Apr 29 '20 20:04 bcallaghan-et