Make Content-Disposition configurable for private downloads

crotown - June 8, 2009 - 16:47
Project:FileField
Version:6.x-3.x-dev
Component:Code
Category:feature request
Priority:normal
Assigned:Unassigned
Status:closed
Description

FileField currently sets the Content Disposition header to "attachment" for most MIME types when a file is downloaded from a filefield. This same behavior broke SWF content uploaded through a filefield and was fixed by adding flash as hard-coded special case that is dowloaded as "inline" rather than "attachment" in #325795: Content-Disposition: attachment breaks swf content and #483232: Content-Disposition header may be incorrect for Flash files.

The MIME type 'audio/midi' could be added to the special cases by adding "|| ereg('^(audio/midi)', $file->filemime)" to the line that sets $disposition, analogously to the previous patch for flash.

But the fact that this is a problem for a rare file type like MIDI is making me think that we may want an administrative interface to create an "exception list" of MIME types that should always be sent with the "inline" disposition rather than following the automatic rule. Then administrators could add a filetype to this list if the need came up, but would feel free to ignore it if they did not see what it was for.

I'd be glad to do the coding on this, if we agree that it is the correct way to go.

#1

crotown - June 10, 2009 - 02:19
Version:6.x-3.0» 6.x-3.x-dev

Here is the change I have in mind to solve this issue. Please be gentle -- this is my first post of a patch. It is rolled against the current dev version.

AttachmentSize
filefield_content_disposition.patch 3.05 KB

#2

bjaspan - June 10, 2009 - 04:08

subscribe

#3

bjaspan - June 10, 2009 - 04:08
Status:active» needs review

#4

crotown - June 10, 2009 - 19:59

I fixed the patch after testing revealed a namespace collision. Here is the improved patch.

AttachmentSize
filefield_content_disposition_v2.patch 3.18 KB

#5

quicksketch - July 3, 2009 - 20:47

Thanks for the patch crotown. I've thought about adding a settings page several times before, especially to help centralize some settings that are currently hidden. However adding a settings page for this particular feature doesn't seem appropriate. The filefield_file_download() function is only used if using private files, which is by far the minority of Drupal sites out there. Making this a setting that is only applicable to some Drupal sites seems excessive.

#6

bjaspan - July 4, 2009 - 04:50

Nate, what do you suggest as an alternative for sites that do use private downloads and want to control download behavior of filefields?

#7

quicksketch - July 4, 2009 - 05:02

To satisfy my indecisive nature regarding a FileField settings page, I'd be happy to have a temporary solution of making the setting but not giving it a UI.

<?php
$inline_types
= variable_get('filefield_inline_types', array('image/*', '*/flash'));
?>

You can then set this setting manually in your settings.php file or using the devel variable editor.

We also need a way to make easy conversions between what user wants to enter (something like "image/*") and what FileField needs to actually do the matching. We're currently using ereg() but if we can use preg_match() I'd be happy with that change. Either way we need to make sure that we maintain the current functionality of images and Flash files being displayed inline by default.

#8

matteogeco - July 7, 2009 - 08:34

Subscribe, I'm interested too in this discussion on Content-Disposition handling, let me know when you ageree on a solution

#9

crotown - July 8, 2009 - 00:48

quicksketch, thanks for the wise opinion and help on this. (And thanks for all the education you've provided through the Lullabot podcast!) I agree that a settings page is not called for with this fix, now that I see how to do without it.

I have redone the fix so that the current functionality is preserved if the variable 'filefield_inline_types' is not set, and the array of strings provided in 'filefield_inline_types' is followed exclusively if it is present.

That means that one has to provide all inline types if one wants to add one. For my MIDI case, I do this via the Devel module's "Execute PHP Code" function with the code:

variable_set('filefield_inline_types',array('image\/*', 'text\/*', 'flash$', 'audio\/midi'));

to add the inline type audio/midi.

Thanks in advance for your thoughts on this patch.

AttachmentSize
content_disposition_485336_9.patch 1.35 KB

#10

quicksketch - July 8, 2009 - 19:30

Nice, this looks great. Only a couple things:

- Let's switch the regex delimiter to a character instead of "/" that isn't allowed in mime-types. "!" is another popular delimiter. That will make it so that the inline types can just be array('image/*', 'text/*', 'flash$').
- Is strlen($inline_type)>0 necessary?

#11

crotown - July 9, 2009 - 18:23

I changed the pattern delimiter to "!" and removed unnecessary backslashes. The strlen() check was not necessary so I removed that as well.

Now I can add the audio/midi and audio/mid types with the PHP code:

variable_set('filefield_inline_types',array('image/*', 'text/*', 'flash$', 'audio/midi?'));

AttachmentSize
content_disposition_485336_11.patch 1.3 KB

#12

quicksketch - July 25, 2009 - 02:58
Status:needs review» fixed

Thanks again crotown, I've modified the patch slightly to trim it up a bit and make the comments fit within the 80 character wrap. Committed the attached patch.

AttachmentSize
filefield_inline_options.patch 1.28 KB

#13

quicksketch - July 25, 2009 - 03:00
Title:Content-Disposition: attachment makes MIDI files download rather than play in browser» Make Content-Disposition configurable for private downloads
Category:bug report» feature request

#14

System Message - August 8, 2009 - 03:10
Status:fixed» closed

Automatically closed -- issue fixed for 2 weeks with no activity.

 
 

Drupal is a registered trademark of Dries Buytaert.