Given the following scenario: I recorded something and want to provide it to someone else. So I render a file, say
a thunderstorm.mp3 and upload it to, say,
http://things.ad001.de/a thunderstorm.mp3. Then I send this link to the recipient using email. Later he answers that he cannot use the link and that I shall attach the file and transmit it via mail.
- Link destroyment It starts with the link in the e-mail. I usually send mails in text/plain. Some receiving mailers cannot stop themselves vom trying to act intelligent and want to identify links and turn them into actual hyperlinks. Unfortunately, most of them do not realize that having an unencoded space in a link may violate specification but be actually quite fine when it is entered into the browser's address bar. The browser will convert ' ' to
%23and it works out.
The mail program will not see this. It will covert
http://things.ad001.de/a thunderstorm.mp3to http://things.ad001.de/a
http://things.ad001.de/adoes not exist, the recipient who clicked the link will see an error 404 and probably say ``woah, that idiot yet again sent me one of his useless links. I really wish he'd use dropbox just as all intelligent people do!''. Then he writes a polite mail to me that there was an error without specifying the error.
And trust me: It can get worse if the URL gets longer. If it gets linewrapped, it may ot only get shortened, it may also receive nasty add-ins: '\n' joins for additionl fun, when the link is not clicked but copy'n'pasted.
- Listening is not having So we got the URL to the recipient as a whole. Congratulations. He then puts it into the browser and navigates actually to my resource. The the browser's magig kicks in. What happens next, depends on a set of magical things. The browser may send a correct mime-type (in this case
audio/mpeg). It recognizes a playable media file and fires up its media player -- and probably will start playing it. The recipient sees my file and fails saving it acutally to his desk. Yet again, he writes me an email, complaining that ``I make things so difficult for him and that I should use dropbox just like everybody else does.''.
Even worse, if the web server's magic does not work out: He sends my MP3 as
text/plainto the browser. In this case, the browser can magically detect this to be actually
audio/mpegand fall back to his media player plugin. Or, worse, can belive the announced content-type and start rendering the MP3 file as text to the user.
Best case scenario: There is no plugin installed and all the browser can do is download the file. This is what we wanted in the first place.
It's suprisingly easy to circumvent all the problems mentioned above.
Instead of uploading the file to
http://things.ad001.de/, create a subdirectory and upload the file to e.g.
http://things.ad001.de/upload1 and hand over this link. Do not put spaces in it. In this case, the link shall be short and bets a good that it will make it to the browser without confusion. The browser will show a file listing. He may even override the web server's default -- whatever. What counts is that the link to the actual file is presented within the browser -- the visible name being
a thunderstorm.mp3 the link pointing to
a%23thunderstorm.mp3. The user can click it -- and maybe a plugin will be activated. But the user can also use the context menu of almost every browser (I really cannot recall a browser not offering this action) and download the linked content. Voila.
You should not start numbering up directories. If I receive a link to
http://files.some.dom/0021/, I will of course also try
http://files.some.dom/0020 and may find files not intended to be seen by me. To avoid this, I use a barcode reader and just use the bar code of something on my desk as directory name. Candy. Office supplies. Water bottles. Barcodes are everywhere. Of course, they can be guessed, too.
Also do not forget, this is by no means secure. If you want to be sure that files are only viewn by those pairs of eyes intended to see them, use encryption and http authentication! Even better, hand them personally on a USB key, if you do not want to trust the web server's integrity.