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

On Sun, Apr 1, 2007, Junio C Hamano wrote:

Jakub Narebski [off-list ref] writes:

quoted

quoted

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

On Tue, Apr 03, 2007 at 16:57 +0200, Jakub Narebski wrote:

On Sun, Apr 1, 2007, Junio C Hamano wrote:

quoted

Jakub Narebski [off-list ref] writes:

quoted

quoted

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 [...]

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.

[...]

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!"

Another example:

  Content-Type: text/plain; charset=utf-8\r
  Content-Disposition: inline; filename*=utf-8'en-US'This%20is%0A%20%2A%2A%2Afun%2A%2A%2A


Although "RFC 2183: The Content-Disposition Header Field" says:

  Parameter values longer than 78 characters, or which contain non-ASCII
  characters, MUST be encoded as specified in [RFC 2184].

the limit of 78 characters is because it is was created for mail, and
some old MUA had limit on line length. It is not the case of HTTP
protocol: lines can be, and are, quite long. Besides for example
Apache 2.0.54 does not understand MUA-style continued HTTP headers
if in 'parse headers' mode: it returns server error.

As to browsers: Mozilla 1.7.12 implements RFC2183 correctly, although for
example shows %0A / \n as a strange symbol in "save as" dialog, created
file has embedded newline in filename, as it should. But both Lynx 2.8.5,
and ELinks 0.10.3 do not implement it fully and without errors.

So that is why we have:

	# It not worth potential problems to try to carry newlines
	# in the header; it is just _suggested_ filename
	$filename =~ s/[[:cntrl:]\n\r]/_/g;


P.S. If there were no objections (no discussion), I'd resend
content_disposition subroutine as patch to gitweb in about a week.

-- 
Jakub Narebski
ShadeHawk on #git
Poland