Incorrect handling of MIME boundaries in MultipartRelatedDecoder ---------------------------------------------------------------- Key: JBWS-1620 URL: https://jira.jboss.org/jira/browse/JBWS-1620 Project: JBoss Web Services Issue Type: Bug Security Level: Public(Everyone can see) Components: jbossws-native Affects Versions: jbossws-1.2.1 Reporter: Janos Biro Assignee: Thomas Diesler Fix For: jbossws-2.0.0 Attachments: MultipartRelatedDecoder.java Original Estimate: 1 week Remaining Estimate: 1 week The MultipartRelatedDecoder handles the MIME boundaries incorrecly: try { // [JBWS-1393] - Problem interpreting messages with attachment when confronted with no <start> header if (start == null) boundary = ("--" + boundaryParameter).getBytes("US-ASCII"); else boundary = ("\r\n--" + boundaryParameter).getBytes("US-ASCII"); } catch (UnsupportedEncodingException e) { throw new WSException("US-ASCII not supported, this should never happen"); } < EATS THE FIRST VALID MIME PART! > // Eat first inner stream since its empty byte[] buffer = new byte[256]; while (delimitedStream.read(buffer) != -1) { } This code assumes that every MIME boundary starts with \r\n but it is not always true for the first one in the message according to RFC1521 boundary := 0*69<bchars> bcharsnospace bchars := bcharsnospace / " " bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" /"_" / "," / "-" / "." / "/" / ":" / "=" / "?" Overall, the body of a multipart entity may be specified as follows: multipart-body := preamble 1*encapsulation close-delimiter epilogue encapsulation := delimiter body-part CRLF delimiter := "--" boundary CRLF ; taken from Content-Type field. ; There must be no space ; between "--" and boundary. close-delimiter := "--" boundary "--" CRLF ; Again, no space by "--", preamble := discard-text ; to be ignored upon receipt. epilogue := discard-text ; to be ignored upon receipt. discard-text := *(*text CRLF) body-part := <"message" as defined in RFC 822, with all header fields optional, and with the specified delimiter not occurring anywhere in the message body, either on a line by itself or as a substring anywhere. Note that the semantics of a part differ from the semantics of a message, as described in the text.> The problem is mayor since e.g. Axis2 generated stubs do not use \r\n before the first MIME boundary, so the MultipartRelatedDecoder eats the first MIME part which would contain the root part so after drops an exception with message "no root part was found" when MTOM is enabled at Axis2 side Reproduction: Use any HTTP client do reproduce it.