On Sun, Apr 1, 2007, Junio C Hamano wrote: > Jakub Narebski <jnareb@xxxxxxxxx> writes: > >>> First is not escaped filename in HTTP header. There was some discussion >>> about this, and even patch by Luben Tuikov which added to_qtext >>> subroutine to deal with escaping in HTTP (which has diferent rules than >>> escaping in HTML, or in HTML attributes) >>> * gitweb: using quotemeta >>> http://thread.gmane.org/gmane.comp.version-control.git/28050/ >>> * [PATCH] gitweb: Convert Content-Disposition filenames into qtext >>> http://thread.gmane.org/gmane.comp.version-control.git/28437 >>> But the patch was newer accepted; either lost in the noise, or in lack >>> of summary to the discussion. >> >> Junio, do you remember by chance why this patch was dropped? > > No, but I suspect that was because the noisiness of the thread > around them suggested they were not ready to be applied. I do > not remember if people submitted the patch and commented on > reached a consensus. Probably not. Here is alternative proposal. It does not implement RFC2184: MIME Parameter Value and Encoded Word Extensions but I'm not sure if 1) it is needed for _HTTP_ Content-Disposition header filename, 2) all browsers implement it. By the way, $str =~ s/[\n\r]/_/g; line (as per Junio Hamano and Petr Baudis suggestion) is needed not only for buggy browsers, but also for buggy CGI implementation: $ perl -wle \ 'use CGI; \ our $cgi = new CGI; \ print $cgi->header(-content_disposition => "inline; filename=\"file\nname\"");' generates (for CGI version 3.10) Content-disposition="inline; filename="file name"" which is a bit strange. Single LF (not CRLF pair) does not need to be quoted in the header, as per RFC822. -- >8 -- # Generate value of Content-Disposition header field, with "inline" # disposition type, for a given filename parameter # Usage: $cgi->header( [...], # -content_disposition => content_disposition($filename)) # References: RFC 2183, RFC 822 and RFC 2045 sub content_disposition { my $filename = shift; #RFC2183: The Content-Disposition Header Field # parameter value containing only non-`tspecials' characters [RFC 2045] # SHOULD be represented as a single `token'. #RFC2045: MIME Part One: Format of Internet Message Bodies # token := 1*<any (US-ASCII) CHAR except SPACE, CTLs, # or tspecials> if ($filename =~ m/[[:space:][:cntrl:]()<>@,;:\\"\/\[\]?=]/) { #RFC2183: The Content-Disposition Header Field # parameter value containing only ASCII characters, but including # `tspecials' characters, SHOULD be represented as `quoted-string'. # It not worth potential problems to try to carry newlines (and such) # in the header; it is just _suggested_ filename $filename =~ s/[[:cntrl:]\n\r]/_/g; #RFC822: Standard for the Format of ARPA Internet Text Messages # quoting is REQUIRED for CR and "\" and for the character(s) that # delimit the token (e.g., "(" and ")" for a comment). However, # quoting is PERMITTED for any character. $filename =~ s/([\\"\r])/\\$1/g; $filename = '"' . $filename . '"'; } return "inline; filename=$filename"; } -- >8 -- P.S. We could probably always quote filename parameter, even if it is not needed ("SHOULD be represented as a single `token'" part). P.P.S. Here is an example of RFC2184 encoded header: Content-Type: application/x-stuff title*1*=us-ascii'en'This%20is%20even%20more%20 title*2*=%2A%2A%2Afun%2A%2A%2A%20 title*3="isn't it!" -- Jakub Narebski Poland - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html