You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are creating the server side for a SOAP based service that uses MTOM/XOP to receive binary files (zip files).
The xsd for the service has the following element definition for the binary file:
<xs:element name="thebinaryfile" type="xs:hexBinary" xmime:contentType="application/octet-stream"/>
We have been using the same approach as demo'ed here (but without all the repository classes etc):
The issue is that when the type "hexBinary" is used, the get'er on the generated request object always returns null. If we change the type to "base64Binary", we get the proper value populated in the byte array.
We send identical requests from SoapUI and see that they reaches the server as expected. But something happens on the receiving side when the libraries are trying to populate the request objects when using "hexBinary" - since the byte field is not populated properly. The fields in the main part of the SOAP request are populated just fine.
If we change the definition in XSD to base64Binary, it can receive the bytes just fine - but would this be safe when the client uses hexBinary? I've used SoapUI with "encodeAttachments" - which are supposed to handle this - and seems to work fine.
This is how the field is generated when using hexBinary:
We are creating the server side for a SOAP based service that uses MTOM/XOP to receive binary files (zip files).
The xsd for the service has the following element definition for the binary file:
<xs:element name="thebinaryfile" type="xs:hexBinary" xmime:contentType="application/octet-stream"/>
We have been using the same approach as demo'ed here (but without all the repository classes etc):
https://github.com/spring-projects/spring-ws-samples/tree/main/mtom/server
The issue is that when the type "hexBinary" is used, the get'er on the generated request object always returns null. If we change the type to "base64Binary", we get the proper value populated in the byte array.
We send identical requests from SoapUI and see that they reaches the server as expected. But something happens on the receiving side when the libraries are trying to populate the request objects when using "hexBinary" - since the byte field is not populated properly. The fields in the main part of the SOAP request are populated just fine.
If we change the definition in XSD to base64Binary, it can receive the bytes just fine - but would this be safe when the client uses hexBinary? I've used SoapUI with "encodeAttachments" - which are supposed to handle this - and seems to work fine.
This is how the field is generated when using hexBinary:
This is how the field is generated when using base64Binary:
Using the following configuration:
The text was updated successfully, but these errors were encountered: