Otherwise, or if the user chooses to save it, we recommend the name picture.png for the file you save it as". Please display it unless you don't know how to display PNG images. Content-Type: image/pngĬontent-Disposition: inline filename="picture.png" Please save it as a file, preferably named picture.png". Means "I don't know what the hell this is. Hence: Content-Type: application/octet-streamĬontent-Disposition: attachment filename="picture.png" 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.
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). 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). 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. 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. 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". The content-type should be whatever it is known to be, if you know it.
0 kommentar(er)
