Re: Issue 261: Check for requirements backing test cases, was: Comments on draft-ietf-httpbis-content-disp

On 03/11/2010, at 6:05 AM, Julian Reschke wrote:

>>> That may be true for Chrome, but certainly *was* not true for IE when I
>>> first encountered the problem (trust me, I *was* sending UTF-8).
>> Indeed.  We don't need to slavishly copy IE.  We just need to stay
>> within some compatibility bound.  Usually we aim for somewhere between
>> 99.99 and 99.999% compatibility.  That usually isn't the same as the
>> unanimous intersection of all browser behavior.
>> ...
> I like numbers. Can we *please* get numbers about actual use, and names of sites that use it?

I like numbers too, but it seems to me that getting these numbers will be difficult, as many use cases for Content-Disposition are behind firewalls or at least password-protected.

So, it may be worthwhile to look at what server-side code we do have access to; Open Source content management frameworks and other serving containers.

I've done a few below, and AFAICT no-one is internationalising their filename parameters, possibly because of the lack of interop that Julian has noted. It also may be that these products don't have wide deployment in markets that need internationalisation; does anyone know of a popular CRM / CMS in asian markets, for example?


SugarCRM 6.1.0RC2, download.php:120 - 

> 		if(isset($_SERVER['HTTP_USER_AGENT']) && preg_match("/MSIE/", $_SERVER['HTTP_USER_AGENT']))
> 		{	
> 			$name = urlencode($name);
> 			$name = str_replace("+", "_", $name);
> 		}
> 		header("Pragma: public");
> 		header("Cache-Control: maxage=1, post-check=0, pre-check=0");
> 		if(isset($_REQUEST['isTempFile']) && ($_REQUEST['type']=="SugarFieldImage"))
> 			header("Content-type: image");
> 		else {
> 		    header("Content-type: application/force-download");
>             header("Content-disposition: attachment; filename=\"".$name."\";");

Ignoring the abomination that is the caching headers there for a moment, you can see that they're UA-sniffing for IE and url-encoding there, but not specifying a charset (even UTF-8), so it's just encoding URL-special characters.

SugarCRM 6.1.0RC2, class.pdf.php:1922 -

>   $fileName = (isset($options['Content-Disposition'])?$options['Content-Disposition']:'file.pdf');
>   header("Content-Disposition: attachment; filename=".$fileName);

i..e, no encoding (here and in all other circumstances I could find).

I would note that Sugar *is* getting deployment in asian markets.


PHP has two C-D related functions:

* http_send_content_disposition - <>
which appears to boil down to <>, line 324. No attempt to encode.

* HttpResponse::setContentDisposition - <>
whose corresponding source is <>, around line 450. There isn't any attempt to encode the parameter in any way there either.


Ruby on Rails' streaming ActionController allows setting Content-Disposition on send_file - <>. 

The corresponding code that sets headers <> doesn't appear to do any encoding (although I'm not familiar with the subtleties of some Ruby syntax).


Django doesn't appear to treat C-D in any special way:

... nor does Plone:

Mark Nottingham

Received on Wednesday, 3 November 2010 00:28:45 UTC