Re: [PATCH] gitweb: Support comparing blobs (files) with different names

[Jakub Narebski <jnareb@gmail.com>]

On Sun, Apr 1, 2007, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> 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=&quot;file
  name&quot;"

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