Attachment Links module for Drupal fixes for in-browser downloads

If to quote the attachment links project on Drupal: The Attachment Links module provides permanent links to files attached to a node. A single, easy-to-remember URL can be used to retrieve the preferred (canonical) or newest version of a file regardless of how many versions of that file have been attached to a node.

Incase the light-bulb didn’t turn on yet for you – with Drupal, if you upload a file attachment then if it doesn’t exist yet it will be saved as .tar.gz. If the user then updates that node with a new file upload of the same name, the filename will change to _1.tar.gz and so on since Drupal will transliterate and correct the filename to make sure such file doesn’t exist yet in it’s files directory.

The Attachment Links module mitigates this problem by allowing you to specify a link like node/2600/attachment and by doing that it’s controller will already pull the correct file attachment for this node and send it over the wire. This enables you to give permanent links (in the form of http://example.com/node/2600/attachment) because otherwise the exact file system link will always change when you update the file entry.

So far that was a somewhat short introduction to the use-case for Attachment Links module.

As with most modules, they don’t always scratch your exact itch (@see http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar guideline number 1), and so for us we had the issue that attachments do no retain their original Content-Type header. Meaning, every file will be forced to download so that if node/2600/attachment is actually sending over a readme.txt file, instead of that file to open up in the browser (which was the required case for us) it got downloaded. Same for images, PDFs, etc.

We found it a bit annoying so worked on a fix to maintain this original behavior while still working with this module. For your enjoyment: http://drupal.org/node/1856422