How to Implement Content-Disposition: Attachment

How to Use Content-disposition for force a file to download to the hard drive?

On the HTTP Response where you are returning the PDF file, ensure the content disposition header looks like:

Content-Disposition: attachment; filename=quot.pdf;

See content-disposition on the wikipedia MIME page.

How to implement Content-Disposition: attachment?

Example of MP3 Lists:

<a href="download.php?file=testing.mp3">Download MP3</a>
<a href="download.php?file=testing2.mp3">Download MP3</a>

download.php :

<?php

$file = $_GET['file'];  

header('Content-type: audio/mpeg');

header('Content-Disposition: attachment; filename="'.$file.'"');

?>

How to set 'Content-Disposition' and 'Filename' when using FileSystemResource to force a file download file?

@RequestMapping(value = "/action/{abcd}/{efgh}", method = RequestMethod.GET)
@PreAuthorize("@authorizationService.authorizeMethod(#id)")
public HttpEntity<byte[]> doAction(@PathVariable ObjectType obj, @PathVariable Date date, HttpServletResponse response) throws IOException {
    ZipFileType zipFile = service.getFile(obj1.getId(), date);

    HttpHeaders headers = new HttpHeaders();
    headers.setContentType(MediaType.APPLICATION_OCTET_STREAM);
    response.setHeader("Content-Disposition", "attachment; filename=" + zipFile.getFileName());

    return new HttpEntity<byte[]>(zipFile.getByteArray(), headers);
}

how to set content-disposition = attachment via javascript?

Content-Disposition is a response header, ie. the server must return it. You can't achieve this with client-side javascript.

What's the use of Content-Type header when the response is an attachment?

Yes it does make sense if you know the what the appropriate Content-Type header is, but NO it is not explicitly required.

RFC6266 Use of the Content-Disposition Header Field in HTTP

According to the original RFC 2616, the disposition type "attachment" only applies to content of type "application/octet-stream". But this restriction has been removed, because recipients in practice do not always check the content type, and it also discourages properly declaring the media type.

So traditionally, we used to have to always specify Content-Type:application/octet-stream to force a download, over time clients evolved and started ignoring it altogether if there was a disposition header header.

Content-Type tells the browser how to interpret the response, but Content-Disposition: attachment tells the browser to treat the response as a file, rather than trying to render it.

But not ALL clients are web browsers, and not all web browsers are equal. By providing the Content-Type as well then you are providing additional information that the client context can use if they choose to, or it will act as a default if for some reason the client does not understand or respect the disposition header, or its value.

By specifying the Content-Type many browsers will use this information to determine the file type restriction to apply on the Save As dialog, which is especially useful if you are NOT also specifying the file name.

Some modern web clients (and extensions for them) will inspect the Content-Type and choose to deliberately pass the content to application or extension that is registered for that type instead of always saving directly to file, even if the Content-Disposition is an attachment. You may have experienced this with PDF viewers.

There are also many older mobile web clients and mini-web browsers embedded within mobile apps that are known to not support Content-Disposition or they deliberately bypass it, instead forcing the content to be rendered directly, so by providing Content-Type when you can then you know that you are providing the most compatible output that you reasonably could.

There is a similar discussion on SO, but not directly a duplicate as this question asks why we might include it Content-Type knowing that it is not likely to be used.

• Do I need Content-Type: application/octet-stream for file download?

How to encode the filename parameter of Content-Disposition header in HTTP?

There is discussion of this, including links to browser testing and backwards compatibility, in the proposed RFC 5987, "Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters."

RFC 2183 indicates that such headers should be encoded according to RFC 2184, which was obsoleted by RFC 2231, covered by the draft RFC above.

---

Related Topics