Spring Web Services
  1. Spring Web Services
  2. SWS-750

SaajSoapMessageFactory's checkForUtf8ByteOrderMark is corrupting input stream

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.5.8, 1.5.9
    • Fix Version/s: 2.0.4
    • Component/s: Core
    • Labels:
      None

      Description

      There appears to be a bug in the implementation of "checkForUtf8ByteOrderMark" in org.springframework.ws.soap.saaj.SaajSoapMessageFactory.

      Under certain circumstances, the call to pushbackInputStream.read(bom) will read less than the required 3 bytes into bom. Then, since the byte order mark isn't found, unread(bom) is called which results in some invalid bytes being added to the stream.

      The contract for PushbackInputStream.read(byte[] b, int off, int len) says "Reads up to len bytes of data." In our case, using Tomcat (versions 6 and 7) with recent releases of Chrome and IE, the call to inputstream.available() in BufferedInputStream's implementation of read returns 0. This is because no more data can be read without blocking. It seems to be just an unfortunate coincidence caused by the size of the header sent by the newest version of chrome and IE. The end result is that our soap envelope is corrupted and our system is unusable.

        Issue Links

          Activity

          Hide
          Arjen Poutsma added a comment -

          This should be fixed now, as we now only unread the amount of bytes that were actually read.

          I do wonder, however, what Chrome and IE have to do with this bug. Are you sending SOAP messages to Spring-WS from these browsers?

          Show
          Arjen Poutsma added a comment - This should be fixed now, as we now only unread the amount of bytes that were actually read. I do wonder, however, what Chrome and IE have to do with this bug. Are you sending SOAP messages to Spring-WS from these browsers?
          Hide
          Zak van der Merwe added a comment -

          Hi Arjen, thanks for your fast response!

          "I do wonder, however, what Chrome and IE have to do with this bug. Are you sending SOAP messages to Spring-WS from these browsers?"
          That's right, we are sending SOAP messages from these browsers. I only included this information in the ticket because it seems strange that we suddenly started to encounter this bug after using spring-ws without problems for a couple of years. We thought it must have something to do with a change in the payload sent by recent versions of these two browsers.

          Your change will fix our issue, but isn't it possible to miss a valid byte order mark if the first read call doesn't read all 3 bytes? It seems like you might need to call read() in a loop until 3 bytes have been read.

          Show
          Zak van der Merwe added a comment - Hi Arjen, thanks for your fast response! "I do wonder, however, what Chrome and IE have to do with this bug. Are you sending SOAP messages to Spring-WS from these browsers?" That's right, we are sending SOAP messages from these browsers. I only included this information in the ticket because it seems strange that we suddenly started to encounter this bug after using spring-ws without problems for a couple of years. We thought it must have something to do with a change in the payload sent by recent versions of these two browsers. Your change will fix our issue, but isn't it possible to miss a valid byte order mark if the first read call doesn't read all 3 bytes? It seems like you might need to call read() in a loop until 3 bytes have been read.
          Hide
          Arjen Poutsma added a comment -

          No problem. I was just wondering about the browser use, I have never seen it before .

          With regard to the fix: yes, it is possible to miss a BOM with this new code. However, I think the PushbackInputStream cannot unread multiple reads, so that would defy the purpose. Having a UTF-8 SOAP message with a BOM is quite uncommon anyway, so I don't think this will bother many users, if any at all.

          Show
          Arjen Poutsma added a comment - No problem. I was just wondering about the browser use, I have never seen it before . With regard to the fix: yes, it is possible to miss a BOM with this new code. However, I think the PushbackInputStream cannot unread multiple reads, so that would defy the purpose. Having a UTF-8 SOAP message with a BOM is quite uncommon anyway, so I don't think this will bother many users, if any at all.
          Hide
          Arjen Poutsma added a comment -

          Closing old issues

          Show
          Arjen Poutsma added a comment - Closing old issues
          Hide
          Pavel Kotlov added a comment -

          Hello,

          having some hard time thinking of a hotfix for a release still using Spring-ws-1.5.9

          After reading this (It describes my problem pretty exact):
          http://forum.springsource.org/showthread.php?131438-Using-spring-ws-behind-https
          I assumed SaajSoapMessageFactory could be the root of my problem.
          I have already created a fixed version of spring-ws with the checkForUtf8ByteOrderMark
          Method fixed but I am still facing the same Problem.

          I face the Problem only on my https server and only when using a special service.

          This is the SOAP Message that is passed to Xerces:
          <nullnullSOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">

          For several reasons I will have to update to spring 3.2 and spring-ws 2.1 in 1-2 months.
          It' just, I can't do it right now.

          Any Help or pointing to the place where my problem could be, will be very much appreciated.

          Show
          Pavel Kotlov added a comment - Hello, having some hard time thinking of a hotfix for a release still using Spring-ws-1.5.9 After reading this (It describes my problem pretty exact): http://forum.springsource.org/showthread.php?131438-Using-spring-ws-behind-https I assumed SaajSoapMessageFactory could be the root of my problem. I have already created a fixed version of spring-ws with the checkForUtf8ByteOrderMark Method fixed but I am still facing the same Problem. I face the Problem only on my https server and only when using a special service. This is the SOAP Message that is passed to Xerces: <nullnullSOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> For several reasons I will have to update to spring 3.2 and spring-ws 2.1 in 1-2 months. It' just, I can't do it right now. Any Help or pointing to the place where my problem could be, will be very much appreciated.
          Hide
          Pavel Kotlov added a comment -

          Hm... after 5 hours of trying different solution I found out that the only code that works for me is:

          SaajSoapMessageFactory.java
              private InputStream checkForUtf8ByteOrderMark(InputStream inputStream) throws IOException {
                  return inputStream;
              }
          

          I will digg into it if the update to 3.2/2.1 want work.

          Show
          Pavel Kotlov added a comment - Hm... after 5 hours of trying different solution I found out that the only code that works for me is: SaajSoapMessageFactory.java private InputStream checkForUtf8ByteOrderMark(InputStream inputStream) throws IOException { return inputStream; } I will digg into it if the update to 3.2/2.1 want work.

            People

            • Assignee:
              Arjen Poutsma
              Reporter:
              Zak van der Merwe
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - Not Specified
                Not Specified
                Logged:
                Time Spent - 31m
                31m