Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SaajSoapMessage does not work if content type includes parameters [SWS-32] #191

Closed
gregturn opened this issue Jun 19, 2006 · 4 comments
Closed
Assignees
Milestone

Comments

@gregturn
Copy link
Contributor

gregturn commented Jun 19, 2006

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");
}

    // 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] + "]");
    }
}

Affects: 1.0 M1

Issue Links:

@gregturn
Copy link
Contributor Author

Luke Hamaty commented

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!

Sorry for any confusion.

@gregturn
Copy link
Contributor Author

Arjen Poutsma commented

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.

@gregturn
Copy link
Contributor Author

Arjen Poutsma commented

Actually, the getVersion() check can be simplified and less fragile by always returning SoapVersion.SOAP_11, since SAAJ 1.2 is SOAP 1.1 only.

SAAJ 1.3 does require the Content-Header check, though.

@gregturn
Copy link
Contributor Author

Arjen Poutsma commented

The issue reported has been fixed, but unfortunately there are other problems with JBoss's SAAJ implementation.
See http://forum.springframework.org/showthread.php?t=26634 and http://www.jboss.com/index.html?module=bb&op=viewtopic&t=86580

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants