I am using the download file API with a downscoped token to allow the user to download files directly from their browser as part of an application where box is hidden from the user (https://developer.box.com/guides/downloads/in-browser/). This works fine, except that the response includes a Content-Disposition header with the value set to “attachment;filename=…”. Ideally, I would want a response with Content-Disposition set to “inline;filename=…” so that the default behavior for browsers would be to preview the file rather than downloading it.
So my questions: Is there a way to force box to return an inline disposition? If not, is there another endpoint/workaround I can use to achieve this (without recreating a preview system myself)?
hmmm! This is an interesting question. Let me look into it and report back.
Alex, Box Developer Advocate
I chatted with our engineering team - there is not a way to change the header value.
Have you looked into to using UI Elements? Specifically content preview?
That’s unfortunate to hear. Perhaps the team could add an optional url parameter that could be passed to allow the header to change? From my understanding all that is required is to change “attachment” to “inline” in the Content-Disposition header, and the browser does the rest of the work.
I can look into that alternate solution. The advantage of inline viewing is that it is simple and fast. The user simply clicks a link from a list and is taken to the file, where they can preview and download as needed. We have attempted other solutions using box and most of them took longer than desired for performance. My concern is that content preview will do the same, as it may require more API calls.
The other advantage is one of UX. Clicking a link allows opening in box directly, no middle-man. Implementing content-preview would require finding a space in our UX for that, or creating another page to display it, slowing performance as it requires a trip to our servers.
Long story short, I can explore that option, but really an inline browser header would be the preferred solution. I would love if you could add that to your potential future feature list.