Uploaded image for project: 'JBoss Web Services'
  1. JBoss Web Services
  2. JBWS-1620

Incorrect handling of MIME boundaries in MultipartRelatedDecoder

    Details

      Description

      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.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  thomas.diesler Thomas Diesler
                  Reporter:
                  biroj Janos Biro
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:

                    Time Tracking

                    Estimated:
                    Original Estimate - 1 week
                    1w
                    Remaining:
                    Remaining Estimate - 1 week
                    1w
                    Logged:
                    Time Spent - Not Specified
                    Not Specified