Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-25039

Updating a BinaryFile with a mismatching mimeType messes up the saved file

    Details

      Description

      When a Content exists with a BinaryFile of mimetype a/something, and it is updated to a new file of mimetype b/something, PlatformUI will send the currently mimeType (a), and the REST API will use this value to store the file. The result is that the file can't be downloaded with the download controller (not found).

      The reason is that it uses the mimeType that is passed instead of building its own.

      On one hand, PlatformUI should maybe send a correct value, but otoh, it isn't required. Passing a wrong mimeType as input shouldn't mess up the stored data, as it is not supposed to have any kind of effect.

        Issue Links

          Activity

          Show
          Bertrand Dunogier added a comment - Bugfix PR https://github.com/ezsystems/ezpublish-kernel/pull/1490 .
          Hide
          Bertrand Dunogier added a comment -

          Why did you remove all the other components Damien ? It does affect the Public API at least.

          Show
          Bertrand Dunogier added a comment - Why did you remove all the other components Damien ? It does affect the Public API at least.
          Hide
          Bertrand Dunogier added a comment -

          Merged to master@a92984d.

          Show
          Bertrand Dunogier added a comment - Merged to master@a92984d .
          Hide
          Rui Silva (Inactive) added a comment -

          Sending back to input queue.
          The proposed fix resolves the download-not-possible / error issue, but when you change the uploaded file from one with a mimetype a/file to another with mimetype b/anotherfile, the downloaded file after updating the content will save the file with the original file mimetype affected extension, example:
          Create file with file image.png (mimetype image/png), publish it, and download it: it will be saved as <image_hash>.png
          Edit content and replace file with video.avi (mimetype video/avi), republish it, and download it: it will be saved as <image_hash>.png, still, instead of as an avi extension file.

          Show
          Rui Silva (Inactive) added a comment - Sending back to input queue. The proposed fix resolves the download-not-possible / error issue, but when you change the uploaded file from one with a mimetype a/file to another with mimetype b/anotherfile, the downloaded file after updating the content will save the file with the original file mimetype affected extension, example: Create file with file image.png (mimetype image/png), publish it, and download it: it will be saved as <image_hash>.png Edit content and replace file with video.avi (mimetype video/avi), republish it, and download it: it will be saved as <image_hash>.png, still, instead of as an avi extension file.
          Hide
          Bertrand Dunogier added a comment -

          Please create a new issue for the extension.

          Show
          Bertrand Dunogier added a comment - Please create a new issue for the extension.
          Hide
          Rui Silva (Inactive) added a comment -

          In regards to the problem found and described at the previous comment, a new issue EZP-25047 was opened instead for that behaviour, and regular QA procedure will hold for this one.

          Show
          Rui Silva (Inactive) added a comment - In regards to the problem found and described at the previous comment, a new issue EZP-25047 was opened instead for that behaviour, and regular QA procedure will hold for this one.
          Hide
          Rui Silva (Inactive) added a comment -

          Tested and approved by QA for master.

          Show
          Rui Silva (Inactive) added a comment - Tested and approved by QA for master.
          Hide
          Gaetano Giunta added a comment -

          A note about new, related bug EZP-28380 : it seems that always getting the mimetype from the physical file instead of letting the user specify one is a regression in capabilities of the cms.
          What I would do is basically the opposite of fix https://github.com/ezsystems/ezpublish-kernel/pull/1490/files#diff-ba20f890d879618a8375660aabfcd8c7R76 :

          • if end user sends in a mimetype along with the file, give the specified mimetype precedence
          • make sure in the GUI layer that when the editor wants to update an existing file, the mimetype of the pre-existing file is not sent along
          Show
          Gaetano Giunta added a comment - A note about new, related bug EZP-28380 : it seems that always getting the mimetype from the physical file instead of letting the user specify one is a regression in capabilities of the cms. What I would do is basically the opposite of fix https://github.com/ezsystems/ezpublish-kernel/pull/1490/files#diff-ba20f890d879618a8375660aabfcd8c7R76 : if end user sends in a mimetype along with the file, give the specified mimetype precedence make sure in the GUI layer that when the editor wants to update an existing file, the mimetype of the pre-existing file is not sent along

            People

            • Assignee:
              Unassigned
              Reporter:
              Bertrand Dunogier
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: