Utility of Http Header "Content-Type: Application/Force-Download" For Mobile

Utility of HTTP header Content-Type: application/force-download for mobile?

Content-Type: application/force-download means "I, the web server, am going to lie to you (the browser) about what this file is so that you will not treat it as a PDF/Word Document/MP3/whatever and prompt the user to save the mysterious file to disk instead". It is a dirty hack that breaks horribly when the client doesn't do "save to disk".

Use the correct mime type for whatever media you are using (e.g. audio/mpeg for mp3).

Use the Content-Disposition: attachment; etc etc header if you want to encourage the client to download it instead of following the default behaviour.

Force image download with php using header() in smartphones and tablets

I got it!

There were differents problems. I found the clear solution in comments from this post:
http://www.digiblog.de/2011/04/android-and-the-download-file-headers/

header("Content-Type: application/octet-stream");
header('Content-Disposition: attachment; filename="test.JPG"');

The important steps: I send everything with a form. The form, to make it work in mobiles, needs to have the target='_top' and the method='get'

It also make errors if the extention (jpg) is not in UPPERCASE and the file name is not between " ".

Now it works in all devices that I try by far. :)

Special thanks to Jörg Wagner, author of the post.

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

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).

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?

---

Related Topics