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

[Jakub Narebski <jnareb@gmail.com>]

On Tue, Apr 03, 2007 at 16:57 +0200, Jakub Narebski wrote:
> 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 [...]
>>>
>>> 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