Problems serving content from Midas: wrong content type for images?

[jcfr]

Problem initially reported by @fedorov

Image uploaded to Midas are associated with the "application/octet-stream" whereas image upload a year ago were associated with "image/png", "image/jpeg", .... .

This is causing problem to embed image. See details in forwarded email.

Note that I confirmed this with both png and jpeg after updating slicer.kitware.com to the current master.

Here are the two images discussed in the forwarded email:

Item1: http://slicer.kitware.com/midas3/item/162714
Mime type: application/octet-stream

Item2: http://slicer.kitware.com/midas3/item/122386
Mine type: image/png

Thanks for your help and insights,
Jc

[fedorov]

Thanks JC! 👍

[jamiesnape]

This is fixed in the upcoming release. It relates to the HTML5 upload form.

[fedorov]

Thanks for the update. Two clarification questions:

• Will the images need to be re-uploaded to have the right mime type?
• What is the estimated date for upgrading this installation with the release that fixes the problem?

[jamiesnape]

Will the images need to be re-uploaded to have the right mime type?

MIME type is only detected on upload, so, unfortunately, yes.

What is the estimated date for upgrading this installation with the release that fixes the problem?

My hope is that it will be within the next month.

[fedorov]

Very unfortunate indeed.

I guess we were fortunate not to upload a lot of images to Midas!

[cpatrick]

If the number is small and you're talking about slicer.kitware.com, we can likely make the necessary modification to the database.

[jcfr]

@jamiesnape Since it is not reasonable/feasible to ask every user to re-upload their images ... Instead of re-uploading, was thinking to fix the database by changing the mimetype to image/png, image/jpg, ... for every item having extension png, jpg, ...

[jamiesnape]

That would work fine.

[jcfr]

Great.

@cpatrick @jamiesnape Will you come up with the set og SQL queries on your side ? Or is it something I should be working on ?

[cpatrick]

@jcfr and I will work together on this when the time comes.

[fedorov]

thanks, will sound good - when the time comes ;)

[jamiesnape]

Fix now merged into master. If someone can test it, I will close the issue.

[jcfr]

Thanks Jamie. Do we still need to update the database to change the mime
type ?

On Fri, Jan 9, 2015 at 10:41 AM, Jamie Snape [email protected]
wrote:

Fix now merged into master. If someone can test it, I will close the issue.

—
Reply to this email directly or view it on GitHub
#81 (comment).

+1 919 869 8849

[jamiesnape]

Yes.

[fedorov]

Thank you! I tested by uploading a new image, and it works as expected.

Would be great if existing images' mime types could be updated without reuploading.

[jamiesnape]

It would and it should not be difficult. If anyone else has more time than me and would like to take it on, it would be very helpful. Otherwise, it will be a week or two before I have a chance to work on it.

[jamiesnape]

Can someone confirm the issue is fixed for newly uploaded images on 3.4.0?

[jcfr]

Hi Jamie,

Thanks for the follow up.

Do you have a link to a 3.4.0 instance that we could test with ?

Jc

On Thu, Apr 2, 2015 at 12:23 PM, Jamie Snape [email protected]
wrote:

Can someone confirm the issue is fixed for newly uploaded images on 3.4.0?

—
Reply to this email directly or view it on GitHub
#81 (comment).

+1 919 869 8849

[jamiesnape]

Good question. Let me get back to you on that.

[fedorov]

I believe it is fixed now, an image I added to Midas yesterday renders fine on this wiki page: https://github.com/QIICR/ProjectIssuesAndWiki/wiki/Use-case-%22Retrospective-data-encoding%22