I think the server infrastructure changed between then and now (including the webserver, IIRC; it used to be Apache, now it's nginx, and I think there's a reverse proxy involved now). What I knew to be true then I don't think is true now.
MIME types can be treacherous territory; server-side they seem innocent enough ("it's just a Content-Type header!"), but when reverse proxying is involved or potentially other devices like load balancers, all of which tend to inspect content, it becomes risky. Apache's
mod_mime_magic can be a blessing and a curse too. Often feels that the days of basic web hosting/content serving are long gone. Things were simpler back then (code directly on an Apache webserver which was directly on the Internet, no intermediary anything).
Reviewing the download links from phpBB (
example), we can see that the Content-Type returned (at least for a
.zip) is
application/octet-stream -- good -- and a Content-Disposition type of
attachment-- which is correct and VERY important -- but the rest of that header looked bizarre to me (those are two apostrophes next to one another BTW, not a double-quote; the asterisk also made me go "?!?!"):
Code: Select all
$ curl -s -v 'http://forums.nesdev.com/download/file.php?id=10609'
* Trying 208.71.141.55...
* TCP_NODELAY set
* Connected to forums.nesdev.com (208.71.141.55) port 80 (#0)
> GET /download/file.php?id=10609 HTTP/1.1
> Host: forums.nesdev.com
> User-Agent: curl/7.59.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx
< Date: Sat, 05 May 2018 03:28:01 GMT
< Content-Type: application/octet-stream
< Content-Length: 284
< Connection: keep-alive
< Keep-Alive: timeout=60
< X-Powered-By: PHP/5.5.9-1ubuntu4.20
< Set-Cookie: XXX
< Set-Cookie: XXX
< Set-Cookie: XXX
< Pragma: public
< Content-Disposition: attachment; filename*=UTF-8''700-in.1_32kib.zip
< Last-Modified: Tue, 31 Oct 2017 22:49:03 GMT
<
* Failed writing body (0 != 284)
* stopped the pause stream!
* Closing connection 0
For Content-Disposition, it looks like
filename* is an
RFC 5987 extension... from 2010, so no wonder I'm not familiar with it. Reading (well, I skimmed) that RFC, it looks as if the syntax is in fact correct. Learned something new. Though, it does make me wonder what happens if you upload a
.txt that's in something other than ASCII or UTF-8, ex. JIS). I'd have to check.
Finally, client-side MIME type association is often a crap shoot as well -- you have no control over how someone's browser is set up/configured, so you don't know what will happen if the client receives a true/literal Content-Type that matches a MIME type that they've configured to allow to auto-run (e.g. "Download as..." vs "Open file"; scarily, a lot of people still do the latter, either automatic or manual). For example, we don't know if someone has
.bat set to automatically run cmd.exe on it, and some jackass uploads one that does
@echo off\rrmdir /q /s C:\WINDOWS. The idea is to minimise the chance of something like that happening. TMK, phpBB doesn't do any kind of "filtering" or "scanning of content" on uploads -- and I tend to fear stuff like that anyway (false positives causing failures that drive the uploader crazy).
These days, all it takes is an intermediary (ex. reverse proxy on the server side, and sometimes even a caching proxy on the client's network (semi-common at workplaces)) to cause a bit of mayhem with MIME types or filtering out certain headers (the latter is VERY common with reverse proxies). The time to worry is when
Content-Type: application/octet-stream becomes, for example,
Content-Type: application/javascript and there's no Content-Disposition header.
