Less restrictive checks in MTOMDecoder

[giovanni-orciuolo]

Makes more MTOM-based services work correctly. Sometimes, some services do not use the exact names in their headers.

[c4milo]

What’s the content type value coming from your service? I believe we should be able to use strings.HasPrefix here.

[giovanni-orciuolo]

What’s the content type value coming from your service? I believe we should be able to use strings.HasPrefix here.

I get this string: Content-Type: application/xop+xml; charset=UTF-8; type="text/xml";

So I believe we could theoretically use application/xop+xml as a prefix

[c4milo]

Right, I have always seen the type and subtype first and extra attributes coming after.

[c4milo]

Yep: https://datatracker.ietf.org/doc/html/rfc2045#section-5.1

[giovanni-orciuolo]

Alright, so can I make a commit with HasPrefix and merge?

[c4milo]

Yes

[c4milo]

If we were to do this better, it would be by using a more robust parser: https://pkg.go.dev/mime

[giovanni-orciuolo]

Yeah, but I believe the only 2 cases we have at the moment are application/soap+xml and text/xml in start-info. Should more cases arise, we should consider using that library

[c4milo]

We also have the one raised in #217

[c4milo]

The one coming in the mtom header.

[giovanni-orciuolo]

I think we both had the exact same problem and solved it in the same way. The commits do the same thing. You can choose which one your prefer to merge ^^

[giovanni-orciuolo]

Can you merge this PR into the base library? I need it in a production environment

[giovanni-orciuolo]

I added more comprehensive checks inside the getBinaryFields function, in order to account for a vast amount of cases in the XML response (e.g. slices, pointers, etc...) in order to populate the binary fields.

[giovanni-orciuolo]

@c4milo Can we merge this?