16

There is a 3d party API with an endpoint http://endpoint/image_id which returns a response with such headers:

content-disposition:attachment; filename=image.png
content-length:27774
content-type:image/png

According to MDN documentation,

In a regular HTTP response, the Content-Disposition response header is a header indicating if the content is expected to be displayed inline in the browser, that is, as a Web page or as part of a Web page, or as an attachment, that is downloaded and saved locally.

Yet, I have to use it like this:

<img src="http://endpoint/image_id">

In Chrome, it works OK for me, I have the image shown. But I have doubts about it. Is it OK?

Mikhail Batcer
  • 1,938
  • 7
  • 37
  • 57
  • 3
    I'm voting to close this question as off-topic because it is requesting a [code review](http://codereview.stackexchange.com/help/on-topic). – Quentin Jan 12 '17 at 15:37
  • 4
    @Quentin It seems to me that you haven't read either the link you provided or my question (or maybe both?), because the question is generally applicable and not about specific piece of code. – Mikhail Batcer Jan 12 '17 at 15:45
  • The point is that with some minor tweaks it would be suitable for code review. – Quentin Jan 12 '17 at 15:52
  • 1
    @Quentin I think you should one more time read the criteria by which a question is considered on-topic for Code Review. And, actually, my question would be quite as clear without any "code" (which it only has in amount of 1 HTML tag). – Mikhail Batcer Jan 12 '17 at 15:56
  • @Quentin I'll consider all other comments for closing without argumentation (like these two) a trolling attempt. – Mikhail Batcer Jan 12 '17 at 15:58
  • You say _"In Chrome, it works OK for me, I have the image shown. But I have doubts about it. Is it OK?"_ .... well, if it should be used in a web page, use `Content-Disposition: inline` (or omit as this is default), if it should be downloaded and saved on the client computer, use `Content-Disposition: attachment`. If an additional `filename="filename.jpg"` parameter is present, the "Save as" dialog will be prefilled with that filename. .... Also, even if some things work they should be done in the way they are suppose to, as documented – Asons Jan 14 '17 at 19:42
  • @LGSon The problem is, I shouldn't change this header, because it is used in other place to actually download images. – Mikhail Batcer Jan 16 '17 at 08:11
  • 2
    Then I recommend you pass some extra parameter, or use an alternative end point, for either downloading or inline usage, as passing wrong meta data just because you don't want to change is a bad thing – Asons Jan 16 '17 at 16:24

2 Answers2

4

If it's OK or not is not so simple.
This is because it implies to two different standards. The HTML Specification and the HTTP Protocol Specification. So it has some greys. It depends upon how the user agent decides to take the response.

According to the http standard the response header indicates that the file should be treated as an attachment.

Howewer here: https://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html

Also says: "If this header is used in a response with the disposition type "attachment" 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."

UPDATE: RFC 6266, remarks that the restriction about the content-type being application/octet-stream is no longer needed

So your content type technically leaves that decision to the user agent (chrome in this case) to show the contents or not.

We are reaching just now some kind of balance between browsers, so to take a wisdom choice today I would recommend to do a cross browser testing.

Ideally this will be in your CI workflow with some tool like souce labs or your custom solution.

Another quick choice will be to upload that simple html example to some host like a free github repo and navigate the raw file from a page like this: https://www.browserling.com/

Which lets you navigate with different OS and browsers a specific url.

Community
  • 1
  • 1
nico
  • 624
  • 11
  • 22
  • RFC 2616 is entirely irrelevant. See RFC 6266 instead. – Julian Reschke Apr 12 '17 at 16:42
  • @JulianReschke I see that you wrote the RFC 6266 and I also see that the RFC 2616 just documents how content disposition works. Please, feel free to suggest how to better rephrase the answer so we can provide a more accurate information. Thanks btw – nico Apr 13 '17 at 00:17
  • the important point being that RFC 6266 does not special-case "application/octet-stream" in any form. – Julian Reschke Apr 14 '17 at 06:37
1

It works because chrome is smart enough to figure that you are using it inside of a web page and it did not display the save as dialog but why do you risk by using 

content-disposition:attachment;

you should instead use :

Content-Disposition: inline

also there has been a question here on stack overflow that had similar answers to your question that explain the difference between using attachement instead of inline have a look on the approved answer on this question.

Community
  • 1
  • 1
Fady Sadek
  • 1,091
  • 1
  • 13
  • 22