Uploaded image for project: 'RESTEasy'
  1. RESTEasy
  2. RESTEASY-1255

MultipartFormDataReader parses EML files that get uploaded

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 3.0.9.Final, 3.6.2.Final
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Steps to Reproduce:
      Hide
      • Use "multipart/form-data" to post an EML file to a resteasy service (eg using apache HttpPost and MultipartEntityBuilder). Set the Content-Type of the FormBodyPart to "message/rfc822"
      • On server use:
        MultipartFormDataInput::getFormDataMap()
        get inputPart from formDataMap
        inputPart.getBody(InputStream.class, null); -> fails
      Show
      Use "multipart/form-data" to post an EML file to a resteasy service (eg using apache HttpPost and MultipartEntityBuilder). Set the Content-Type of the FormBodyPart to "message/rfc822" On server use: MultipartFormDataInput::getFormDataMap() get inputPart from formDataMap inputPart.getBody(InputStream.class, null); -> fails

      Description

      We use a MultipartFormDataReader to process our "multipart/form-data" (multiple files uploaded via POST). We use inputPart.getBody(InputStream.class, null) to get the binary content of the uploaded files.

      Everything worked well until someone tried to upload an EML/rfc822 file.
      Turns out the EML gets parsed as part of the request and turned into objects. All other files/mimetypes stay in binary form. EML files turn up as Message objects where the getBody doesn't work with InputStream.
      This only happens when the Content-Type of the "formpart" is set to "message/rfc822". So it really does not depend on the content of the file transmitted!

      Turns out MultipartFormDataReader uses MultipartInputImpl::BinaryMessage. There a mime4j MimeStreamParser is created, which in turn uses MimeTokenStream. That stream supports MIME as well as rfc822 parsing which results in EML files being parsed. Even attachments in the attached email get parsed.

      We obviously don't want the files to be touched and have no control over how the client sends this information. So I looked into how to change this:
      MimeTokenStream has a way to control the recursion mode: setRecursionMode
      If I set RecursionMode.M_NO_RECURSE there, it won't start parsing any mimeparts in the post request.

      Unfortunately this can't be set easily in mime4j 0.6 because the MimeTokenStream is not exposed. I could only solve by patching mime4j. I added a setNoRecurse() to MimeStreamParser and call this in BinaryMessage after creating the parser. Then everything works as expected.
      mime4j 0.7 has a new constructor MimeStreamParser(MimeTokenStream tokenStream) which allows to set the streams no_recurse flag.
      To make it even easier, I submitted a push request to mime4j to support the settting via a method: https://github.com/apache/james-mime4j/pull/4

      I would like to see that fixed in a new version of Resteasy though. How can I help?

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  Unassigned
                  Reporter:
                  fknecht Felix Knecht
                • Votes:
                  4 Vote for this issue
                  Watchers:
                  6 Start watching this issue

                  Dates

                  • Created:
                    Updated: