Missing Content-Disposition in raw_datastream view
Closed this issue · 5 comments
When I download a file directly from fedora, get the content-disposition header set. When I download it through the raw_datastream view, I do not see this header. This is useful if you want to make sure a datastream is downloaded with a specific filename as passed through from fedora.
This made a difference when returning Digital Negative files (dng) which end up having a mimetype image/tiff. I received a file named download.tif as opposed to ORIGINAL_NAME.dng
I'm willing to work on this but not sure where to start.
Thanks for reporting the issue. Somehow this use case hasn't come up for us, and I think we're generally setting download filenames in the django views that call raw_datastream.
The header will have to be pulled from the Fedora response and added to the HttpResponse that's created here:
https://github.com/emory-libraries/eulfedora/blob/master/eulfedora/views.py#L213
.. but getting the header from the Fedora response might be a little tricky since the code is currently using the DatastreamObject get_chunked_content method to avoid reading a whole datastream into memory at once. I presume the header you want is available on the response object returned by the api, but I don't see an obvious way to get it since get_chunked_content is a generator.
The best I can currently think of is to store relevant header information somewhere on the DatastreamObject so it can be picked up in the view. Hopefully we could store it in a more meaningful way rather than just "last datastream response headers". Thoughts?
It occurs to me that newer versions of Fedora than what we're currently running probably also provide additional information that's being calculated by the raw_datastream view, and if we could just pass them through that should be more efficient and accurate than handling them in eulfedora.
It just occurred to me that there is an easier way to fix this - rather than the view calling the DatastreamObject get_chunked_content method, it should just use the api getDatastreamDissemination method directly, which will return a response object that has all the headers as well as access to the content. I think that would actually be pretty straightforward.
@jrhoads do you want to try fixing this?
Thank You @rlskoeser
I will take a look at this on Monday.