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
org.springframework.ws.soap.saaj.SaajSoapMessage#getVersion() inpects the Content-Type header to determine the SOAP version, but it is using a simple String equals that does not recognize parameters on the content type. (See http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7). As a result, getVersion throws an exception if the Content-Type includes an encoding e.g.:
Content-Type: text/xml;charset=UTF-8
My corrected version of the function:
public SoapVersion getVersion() {
String[] contentTypes = saajMessage.getSOAPPart().getMimeHeader(CONTENT_TYPE_HEADER);
if (ObjectUtils.isEmpty(contentTypes)) {
throw new SaajSoapMessageException("Could not read '" + CONTENT_TYPE_HEADER + "' header from message");
}
// Ignore parameters in content type (see http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7)
int i = contentTypes[0].indexOf(';');
if (i >= 0) {
contentTypes[0] = contentTypes[0].substring(0, i);
}
if (SoapVersion.SOAP_11.getContentType().equals(contentTypes[0])) {
return SoapVersion.SOAP_11;
}
else if (SoapVersion.SOAP_12.getContentType().equals(contentTypes[0])) {
return SoapVersion.SOAP_12;
}
else {
throw new SaajSoapMessageException("Unknown content type [" + contentTypes[0] + "]");
}
}
More info:
Apparently my runtime environment was picking up jboss-saaj.jar from JBoss 4.0.4GA. The Sun JWSDP 1.6 saaj.jar does not exhibit this behavior (it apparently strips the encoding= part on its own).
The jboss-saaj.jar also does not set the content type on the created response message, which causes similar problems in org.springframework.ws.transport.http.MessageHandlerAdapter#handle, with no easy fix.
So, this is really a SAAJ implementation compatibility issue, possibly peculiar to the JBoss implementation, and typical of the tiny details that bedevil WS standards!
Yeah, SAAJ is part of the J2EE 1.4 spec, so your application server probably uses its own version.
Thanks for the fix! I will include it now.
With regard to the response message, I think I can fix that in the SaajSoapMessageContext#createSoapMessageInternal. Basically, we can just copy the content type from the request message, to make sure that the SOAP version stays the same.
Luke Hamaty opened SWS-32 and commented
org.springframework.ws.soap.saaj.SaajSoapMessage#getVersion() inpects the Content-Type header to determine the SOAP version, but it is using a simple String equals that does not recognize parameters on the content type. (See http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7). As a result, getVersion throws an exception if the Content-Type includes an encoding e.g.:
Content-Type: text/xml;charset=UTF-8
My corrected version of the function:
public SoapVersion getVersion() {
String[] contentTypes = saajMessage.getSOAPPart().getMimeHeader(CONTENT_TYPE_HEADER);
if (ObjectUtils.isEmpty(contentTypes)) {
throw new SaajSoapMessageException("Could not read '" + CONTENT_TYPE_HEADER + "' header from message");
}
Affects: 1.0 M1
Issue Links:
("is depended on by")
The text was updated successfully, but these errors were encountered: