594

The HTTP standard says:

If this header [Content-Disposition: attachment] is used in a response with the application/octet-stream content-type, the implied suggestion is that the user agent should not display the response, but directly enter a `save response as...' dialog.

I read that as

Content-Type: application/octet-stream
Content-Disposition: attachment

But I would have thought that Content-Type would be application/pdf, image/png, etc.

Should I have Content-Type: application/octet-stream if I want browsers to download the file?

Paul Draper
  • 78,542
  • 46
  • 206
  • 285

1 Answers1

1339

No.

The content-type should be whatever it is known to be, if you know it. application/octet-stream is defined as "arbitrary binary data" in RFC 2046, and there's a definite overlap here of it being appropriate for entities whose sole intended purpose is to be saved to disk, and from that point on be outside of anything "webby". Or to look at it from another direction; the only thing one can safely do with application/octet-stream is to save it to file and hope someone else knows what it's for.

You can combine the use of Content-Disposition with other content-types, such as image/png or even text/html to indicate you want saving rather than display. It used to be the case that some browsers would ignore it in the case of text/html but I think this was some long time ago at this point (and I'm going to bed soon so I'm not going to start testing a whole bunch of browsers right now; maybe later).

RFC 2616 also mentions the possibility of extension tokens, and these days most browsers recognise inline to mean you do want the entity displayed if possible (that is, if it's a type the browser knows how to display, otherwise it's got no choice in the matter). This is of course the default behaviour anyway, but it means that you can include the filename part of the header, which browsers will use (perhaps with some adjustment so file-extensions match local system norms for the content-type in question, perhaps not) as the suggestion if the user tries to save.

Hence:

Content-Type: application/octet-stream
Content-Disposition: attachment; filename="picture.png"

Means "I don't know what the hell this is. Please save it as a file, preferably named picture.png".

Content-Type: image/png
Content-Disposition: attachment; filename="picture.png"

Means "This is a PNG image. Please save it as a file, preferably named picture.png".

Content-Type: image/png
Content-Disposition: inline; filename="picture.png"

Means "This is a PNG image. Please display it unless you don't know how to display PNG images. Otherwise, or if the user chooses to save it, we recommend the name picture.png for the file you save it as".

Of those browsers that recognise inline some would always use it, while others would use it if the user had selected "save link as" but not if they'd selected "save" while viewing (or at least IE used to be like that, it may have changed some years ago).

Jon Hanna
  • 110,372
  • 10
  • 146
  • 251
  • 1
    Uploading a file with the default enctype would be incorrect and perhaps the result of that triggered some attack detection, rather than just falling to make the file contents available. – Jon Hanna Apr 04 '15 at 18:22
  • *Can you elaborate on the second example for the following:* what if the client/user wants to save it but the browser is able to view it? So I want to send a request to an image that I want to save rather than show in browser...? How to handle request/response object/headers in such a case? – Wilt Apr 09 '15 at 12:53
  • 12
    @Wilt if the client wants to save it, then it doesn't matter what headers are sent (you can "save" or "save link as" on anything in your browser), as the headers are information, not rules so `attachment` could be considered "best not to display this yourself" while `inline` as "best to display this yourself if you can". Either way, most browsers will use the filename value as the suggested name of the file, but users can always override that. – Jon Hanna Apr 09 '15 at 14:12
  • 1
    @JonHanna To me, it's simply due to three points. Some other answers recommend to use a *non-sense* or `application/octet-stream` `Content-Type` for downloading files. You don't. They also recommend to set `attachment` to `Content-Disposition`. You don't. Your explanation makes me feel clear and comfortable. Theirs don't. – Lewis Jul 18 '15 at 09:30
  • I laughed and then upvoted for > Means "I don't know what the hell this is. Please save it as a file, preferably named picture.png". Oh and also because the answer is very helpful. – aaaaaa Oct 05 '17 at 08:26
  • 1
    Chrome will still open PDF instead of downloading it. hah – zhuhang.jasper Mar 26 '19 at 05:46
  • 1
    If Chrome is opening the PDF instead of downloading it, is it because Chrome is set to be the default app for displaying PDF files? – Joel B Apr 18 '19 at 20:08
  • 2
    I just got an issue with text files that have BOM (byte-order-mark). As many know, to make Excel show international symbols in CSV files, you have to encode your CSV as UTF16 LE with BOM. So, I sent the file as `text/csv` but it could not be opened. It turned out, HTTP client is doing some additional re-encoding and replaces BOM with garbage. The only way to prevent it from doing so was to specify `binary/octet-stream`. I did not try `application/octet-stream` yet because `binary` seemed to be more explicit about what I wanted to achieve. – JustAMartin Jul 16 '19 at 09:50
  • 7
    things works like this in most cases, however, iOS13/iOS14 safari still open the pdf files (only PDF) on the current tab. need to set to `octet-stream` so that a download window can pop up – suyuan xu Nov 05 '20 at 20:11
  • 1
    This is not working. I've tried sending Content-Type as `text/csv` and `application/octet-stream` both with `Content-Disposition: attachment; filename=` but this is not working when this api is called from FE. This API is a POST one. The browser is displaying the correct response in network tab but its not prompting to download neither it is saving the file automatically. – y_159 Dec 07 '21 at 07:17