News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

[url=http://forum.simutrans.com]forum[/url] content type of attachments

Started by captain crunch, November 27, 2015, 02:39:36 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

captain crunch

The forum delivers attached images as Content-Type: application/octet-stream [1] whereas it should be one of image/[some-image-format].

[1]HEAD "http://forum.simutrans.com/index.php?action=dlattach;topic=14964.0;attach=25344"
200 OK
Cache-Control: no-cache
Connection: close
Date: Fri, 27 Nov 2015 14:35:36 GMT
Pragma:
Accept-Ranges: bytes
ETag: "25344simscr03.JPG1448583065"
Server: Apache/2.2.29 (Unix) mod_ssl/2.2.29 OpenSSL/1.0.1e-fips mod_bwlimited/1.4
Content-Encoding: none
Content-Type: application/octet-stream
Expires: Sat, 26 Nov 2016 14:35:36 GMT
Last-Modified: Fri, 27 Nov 2015 00:11:05 GMT
Content-Disposition: attachment; filename="simscr03.JPG"
Content-Transfer-Encoding: binary
X-Clacks-Overhead: GNU Terry Pratchett
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Powered-By: PHP/5.4.36
X-XSS-Protection: 1


Ters

Is this a problem? I have to deal with a system that delivers flash files with content type text/html, and only Internet Explorer has problems with that. Internet Explorer does however not get confused by images as octet-stream.

captain crunch

Yes, this is a problem. A proper web browser asks the user what to do with the file or where to save it.

Ters

Funny that Mozilla says MIME types are important, when I had to use their browser to get around the problem of wrong MIME type. Or perhaps worrying that the work-around may soon no longer work. Some circumstances are different, though.

However, I think the fact that a proper browser wants to save the file is exactly why the content type is application/octet-stream. Attached images are shown inline. The thumbnail itself is a link that opens the image in full size in a new window. That URL has a content type of image/<whatever>. The link below the image is probably intended for downloading the image, and therefore utilizes the trick of using application/octet-stream to prevent the browser from trying to open the image itself.

captain crunch

Indeed, the link from the image is different from the link below the image. The first opens the image, the second asks for saving the downloaded image. This never occurred to me before. Did you discover this for yourself or is there some indication in the user interface?

Ters

I think I've only ever clicked on the image before. When I tried that to verify your observation, I noticed the URL was different from the HTTP response you posted.

The paperclip might be the user interface's attempt at telling something. Other than that, for non-images, there is only the link for downloading, so perhaps they intended plain links to consistently be downloading.