It works amazingly well for files that are embedded, but some lecturers like to mark their files as ‘force download’. For normal people I assume this isn’t much of a problem, but whenever I go looking for a file that comes from Learn my downloads folder isn’t the first place I look, so I typically end up with duplicates of duplicates clogging up my downloads.
Instead of changing my habits (or studying for discrete math like I was meant to) I had a look into what causes a browser to download a file rather that display it. There are a number of ways that you can do this; in HTML 5 there is a
download flag that you can add to a link that tells the browser to download it - but only if that browser is Chrome, Opera or Firefox. Moodle (aka Learn) is firmly rooted in the ’00s and so this wasn’t being used - if it was then it would be trivial to remove that flag from certain links.
Next up was the
content-type of the request - if it is set to
application/x-forcedownload then the browser will save it. Sure enough the response from Moodle came back with
Another option would be to make a proxy that would get the data and then send a new response back with a brand new header, but a quick
wget showed that Learn checks for a cookie when you try to get the file. Plus it would be really slow and require a server just to run this silly script.
content-disposition. It turns out that the content type isn’t the only thing that determines if the file should be displayed or downloaded.
content-disposition allows you to specify that the file is an attachment and it should have a certain filename. Some more Google-fu and I changed this to
inline and bam, inline PDFs with no forced downloading.
If you do use Moodle or Blackboard on Chrome, you can download Learn Enhancer to ease your eyes.