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

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