[SWS-750] SaajSoapMessageFactory's checkForUtf8ByteOrderMark is corrupting input stream Created: 20/Jan/12  Updated: 20/Aug/13  Resolved: 24/Jan/12

Status: Closed
Project: Spring Web Services
Component/s: Core
Affects Version/s: 1.5.8, 1.5.9
Fix Version/s: 2.0.4

Type: Bug Priority: Critical
Reporter: Zak van der Merwe Assignee: Arjen Poutsma
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: 31m
Original Estimate: Not Specified

Issue Links:
relates to SWS-845 checkForUtf8ByteOrderMark() will not ... Resolved


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.

Comment by Arjen Poutsma [ 24/Jan/12 ]

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?

Comment by Zak van der Merwe [ 24/Jan/12 ]

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.

Comment by Arjen Poutsma [ 25/Jan/12 ]

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.

Comment by Arjen Poutsma [ 04/May/12 ]

Closing old issues

Comment by Pavel Kotlov [ 10/Mar/13 ]


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):
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.

Comment by Pavel Kotlov [ 10/Mar/13 ]

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.

Generated at Mon Oct 22 22:00:08 UTC 2018 using JIRA 7.9.2#79002-sha1:3bb15b68ecd99a30eb364c4c1a393359bcad6278.