Uploaded image for project: 'Spring Web Services'
  1. Spring Web Services
  2. SWS-32

SaajSoapMessage does not work if content type includes parameters

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 1.0 M1
    • Fix Version/s: 1.0 M2
    • Component/s: Core
    • Labels:
      None

      Description

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

      }

        Issue Links

          Activity

          Hide
          wlhamaty Luke Hamaty added a comment -

          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.

          Show
          wlhamaty Luke Hamaty added a comment - 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.
          Hide
          arjen.poutsma Arjen Poutsma added a comment -

          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.

          Show
          arjen.poutsma Arjen Poutsma added a comment - 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.
          Hide
          arjen.poutsma Arjen Poutsma added a comment -

          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.

          Show
          arjen.poutsma Arjen Poutsma added a comment - 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.
          Hide
          arjen.poutsma Arjen Poutsma added a comment -

          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

          Show
          arjen.poutsma Arjen Poutsma added a comment - 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

            People

            • Assignee:
              arjen.poutsma Arjen Poutsma
              Reporter:
              wlhamaty Luke Hamaty
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: