[JBoss JIRA] Commented: (JBWS-1620) Incorrect handling of MIME boundaries in MultipartRelatedDecoder
by Darran Lofthouse (JIRA)
[ https://jira.jboss.org/jira/browse/JBWS-1620?page=com.atlassian.jira.plug... ]
Darran Lofthouse commented on JBWS-1620:
----------------------------------------
The lack of this fix can cause the following error to be reported: -
11:20:36,456 ERROR [SOAPFaultHelperJAXRPC] SOAP request exception
java.lang.IllegalArgumentException: multipart/related stream invalid, no root part was found
at org.jboss.ws.core.soap.attachment.MultipartRelatedDecoder.decodeMultipartRelatedMessage(MultipartRelatedDecoder.java:156)
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 12 months
- 1
- 0