From: Dave Date: Wed, 04 Mar 2009 23:52:09 GMT Subject: Re: [Orinoco-users] linux-firmware binary corruption with gitweb Message-ID: <49AF1429.9080009@gmail.com> In-Reply-To: Jakub Narebski wrote: > Dave writes: >>> My strong impression is that the recoding takes place on the server. I >>> think the bug should be reported to the gitweb maintainers unless it a >>> local breakage on the kernel.org site. >> Thanks Pavel. >> >> I just did a quick scan of the gitweb README - is this an issue with the >> $mimetypes_file or $fallback_encoding configurations variables? > > First, what version of gitweb do you use? It should be in 'Generator' > meta header, or (in older gitweb) in comments in HTML source at the > top of the page. Not sure where I'd find the meta header, but at the top of the HTML: > Second, the file is actually sent to browser 'as is', using binmode :raw > (or at least should be according to my understanding of Perl). And *.bin > binary file gets application/octet-stream mimetype, and doesn't send any > charset info. git.kernel.org should have modern enough gitweb to use this. > Strange... Dug around gitweb.perl in the main git repo. Then looked at the git/warthog9/gitweb.git repo (after noting the Git Wiki says kernel.org is running John Hawley's branch). One notable change to git_blob_plain: undef $/; binmode STDOUT, ':raw'; - print <$fd>; + #print <$fd>; + $output .= <$fd>; binmode STDOUT, ':utf8'; # as set at the beginning of gitweb.cgi $/ = "\n"; close $fd; + + return $output; If that's the code that's running, doesn't that mean the output mode change doesn't impact the concatenation to $output? So the blob gets utf encoding when actually printed. Regards, Dave.