jersey
  1. jersey
  2. JERSEY-1667

Incorrect handling of file upload errors when temp files cannot be written

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.17
    • Fix Version/s: 1.18
    • Component/s: media
    • Labels:
      None
    • Environment:

      64bit Linux, JDK 1.7 u11

      Description

      When uploading non-miniscule files when java.io.tmpdir is set to somewhere that does not exist or otherwise is not writeable, the following occurs:

      • MultiPartReaderClientSide invokes mimepull (see line 187) to get attachments
      • mimepull allocates a little bit of space in memory, then falls back to writing temp files
      • This fails with an IOException, which is then wrapped in MIMEParsingException
      • This is caught on MultiPartReaderClientSide:145, which assigns Status.BAD_REQUEST to the resulting WebApplicationException
      • This goes through the usual exception handling code to arrive at ContainerResponse:486, which checks if the response status >= 500. Since it is not, and since the logging level is typically not <= FINE, no logging happens.

      This is very confusing to the hapless developer since a well-formed request is silently rejected with a 400.

      For ease of reproduction, a simple test case is here; https://github.com/marshallpierce/jersey-file-upload-test

      It seems to me that MIMEParsingException should not be assigned BAD_REQUEST no matter what, since at least in this case it's definitely not a bad request. Perhaps inspect the cause chain of MIMEParsingException to see if an IOException is involved or something like that?

        Activity

        Hide
        Marek Potociar added a comment -

        Targeting for both 1.18 and 2.0 - when fixing in 1.x, we need to make sure the bug does not occur in 2.0.

        Show
        Marek Potociar added a comment - Targeting for both 1.18 and 2.0 - when fixing in 1.x, we need to make sure the bug does not occur in 2.0.

          People

          • Assignee:
            Michal Gajdos
            Reporter:
            mpierce
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 6 hours
              6h
              Remaining:
              Remaining Estimate - 0 minutes
              0m
              Logged:
              Time Spent - 3 hours Time Not Required
              3h