SaajSoapMessageFactory's checkForUtf8ByteOrderMark is corrupting input stream [SWS-750]

[gregturn]

Zak van der Merwe opened SWS-750 and commented

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.

---

Affects: 1.5.8, 1.5.9

Issue Links:

• checkForUtf8ByteOrderMark() will not detect BOM with some TLSv1 implementations [SWS-845] #919 checkForUtf8ByteOrderMark() will not detect BOM with some TLSv1 implementations

Referenced from: commits 8ac15a2

1 votes, 2 watchers

[gregturn]

Arjen Poutsma commented

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?

[gregturn]

Zak van der Merwe commented

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.

[gregturn]

Arjen Poutsma commented

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.

[gregturn]

Arjen Poutsma commented

Closing old issues

[gregturn]

Pavel Kotlov commented

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.

[gregturn]

Pavel Kotlov commented

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

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

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