search

irods-contrib / irods-cloud-browser

DFC Web Based cloud browser
BSD 2-Clause "Simplified" License
19 stars 13 forks source link

Make content-disposition a parameter? #160

Open scroogie opened 8 years ago

scroogie commented 8 years ago

Would it be possible to make content-disposition for the file download service optionally inline and leave out the application/octet-stream content-type? We would like to display some images directly from iRODS in a custom frontend.

scroogie commented 8 years ago

Just fyi, without the Type header (application/octet-stream) and

dls.contentDispositionHeader = "inline;filename=\"${name}\""

in FileService.groovy and

response.setHeader("Content-disposition", dfs.contentDispositionHeader)

in FileService.groovy (it was hardcoded there, no matter what was set in DFS), it works as expected (displaying e.g. pngs inline and getting a Download window for e.g. tar.gz etc.

michael-conway commented 8 years ago

thanks we'll push this into the release that should happen in the next 2 weeks!

On Mon, May 2, 2016 at 7:25 AM, scroogie notifications@github.com wrote:

Just fyi, without the Type header (application/octet-stream) and

dls.contentDispositionHeader = "inline;filename=\"${name}\""

in FileService.groovy and

response.setHeader("Content-disposition", dfs.contentDispositionHeader)

in FileService.groovy (it was hardcoded there, no matter what was set in DFS), it works as expected (displaying e.g. pngs inline and getting a Download window for e.g. tar.gz etc.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/irods-cloud-browser/issues/160#issuecomment-216209038

michael-conway commented 8 years ago

fixed for release

JustinKyleJames commented 7 years ago

We are going to have to find another fix for this one because the changes listed above removed the ability to download single files (*.txt, etc.)

scroogie commented 6 years ago

@JustinKyleJames This is probably because it was never fixed as I suggested. If you look at the commit, it didn't set the header as I suggested, but hardcoded it to a different value. :/

JustinKyleJames commented 6 years ago

Thanks for the info. I will try out what you suggested.

JustinKyleJames commented 6 years ago

By the way, the consensus when we were discussing this was rather than being able to view images inline they would add functionality to view rather than download so people can download images, etc. if they desire.

scroogie commented 6 years ago

Hi James,

the consensus when we were discussing this was rather than being able to view images inline they would add functionality to view rather than download so people can download images, etc. if they desire.

I'm not sure I understand correctly. What you describe is exactly what was desired with this patch. The problem with the old version is that it sends a content disposition header with the FILE itself, meaning you cannot embed it, even when you write seperate Frontend code for it in Cloud Browser. When loading the image, e.g. in an img src, it will still offer to download, due to the header!

This is basically what we are trying. On the one hand we are embedding cloud browser, but we still use some self-written frontend code to display e.g. some graphs of data. We also want to offer download links (deep linked, e.g. direct download links).