# [RFC/PATCH] gitweb: Try to sanitize mimetype for 'blob_plain' view 3 messages from 2007-11-19 to 2007-11-20. Participants: Jakub Narebski, Junio C Hamano. Thread: https://gitlist.dev/t/10931 ## Jakub Narebski, 2007-11-19 14:54 Subject: [RFC/PATCH] gitweb: Try to sanitize mimetype for 'blob_plain' view Message-ID: <1195484054-18164-1-git-send-email-jnareb@gmail.com> URL: https://gitlist.dev/e/1195484054-18164-1-git-send-email-jnareb%40gmail.com ``` Use 'text/plain' for files which are text and can be viewed in a browser, and are not among a few 'text/*' mimetypes universally recognized by web browsers. This means files with 'text/*' which are not text/html, text/css, text/sgml or text/xml, and files with 'application/x-*' mimetype which are nevertheless text: javascript, shell, Perl, Tcl, (La)TeX,... Signed-off-by: Jakub Narebski --- Tired of my web browser (Mozilla) asking me what I want to do with shell script, Perl script or LaTeX document when using 'blob_plain' (raw) view, because of declaration in mimetypes file I have added mimetype sanitizing to gitweb. It is an RFC partially because list of mimetypes is a bit arbitrary. Additionally I guess that the mimetype sanitizing should be separated into subroutine. But most of all beause proper solution is to create mimetype file for use by gitweb. gitweb/gitweb.perl | 23 ++++++++++++++++++++++- 1 files changed, 22 insertions(+), 1 deletions(-) diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl index 491a3f4..1cfe293 100755 --- a/gitweb/gitweb.perl +++ b/gitweb/gitweb.perl @@ -2366,7 +2366,28 @@ sub blob_mimetype { if ($filename) { my $mime = mimetype_guess($filename); - $mime and return $mime; + + if ($mime) { + # try to sanitize mimetype + + # return text/plain on unknown text/* mimetype + if ($mime =~ m!^text/! && + $mime !~ m!^text/(?:html|css|sgml|xml)$!) { + return 'text/plain' . + ($default_text_plain_charset ? + '; charset='.$default_text_plain_charset : ''); + } + # return text/plain for known programming languages and like + if ($mime =~ m!^application/x-(?: + javascript|csshell|shell|csh|perl| + sh|shar|tcl|latex|tex|texinfo)!x) { + return 'text/plain' . + ($default_text_plain_charset ? + '; charset='.$default_text_plain_charset : ''); + } + # otherwise return mimetype found in mimetypes file(s) + return $mime; + } } # just in case -- 1.5.3.5 ``` ## Junio C Hamano, 2007-11-20 08:07 Subject: Re: [RFC/PATCH] gitweb: Try to sanitize mimetype for 'blob_plain' view Message-ID: <7vlk8tl4pv.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vlk8tl4pv.fsf%40gitster.siamese.dyndns.org In-Reply-To: <1195484054-18164-1-git-send-email-jnareb@gmail.com> ``` Jakub Narebski writes: > Use 'text/plain' for files which are text and can be viewed in a > browser, and are not among a few 'text/*' mimetypes universally > recognized by web browsers. This means files with 'text/*' which are > not text/html, text/css, text/sgml or text/xml, and files with > 'application/x-*' mimetype which are nevertheless text: javascript, > shell, Perl, Tcl, (La)TeX,... > > Signed-off-by: Jakub Narebski > --- > Tired of my web browser (Mozilla) asking me what I want to do with > shell script, Perl script or LaTeX document when using 'blob_plain' > (raw) view,... I admit that I share the irritation, but I've felt that solving it this way by discarding information is going backwards, and the kosher solution is to tell the browser what to do with these unknown mimetypes. Unfortunately this needs to be done by the user -- I do not think the server can. On the other hand, maybe the people who are browsing the plain view from the browser do not need to have the content marked as written in what programming language. I dunno. ``` ## Jakub Narebski, 2007-11-20 10:58 Subject: Re: [RFC/PATCH] gitweb: Try to sanitize mimetype for 'blob_plain' view Message-ID: <200711201158.06029.jnareb@gmail.com> URL: https://gitlist.dev/e/200711201158.06029.jnareb%40gmail.com In-Reply-To: <4BAE81C8-EFF3-473D-B243-B7D0F66F131B@wincent.com> ``` Wincent Colaiuta wrote: > So yes, this is discarding information -- in a sense it is actually   > removing *correct* configuration from the server side to work around   > undesired behaviour on the client side -- but it gave the behaviour I   > wanted. So I think this patch is actually a good idea, because the   > behaviour (the user experience) is more important than adhering to a   > standard just because its a standard. Modifying gitweb to work around not configured web browser and mime.types not written for gitweb like in this RFC patch is one way of solving this. Is it good way? That is why it is an RFC... well that and details of sanitization. Another would be to use mime.types crafted specially for gitweb, and use it for $mimetypes_file (gitweb falls back to /etc/mime.types if it is not defined or not present). This might be better solution. QUESTION: Currently gitweb checks if $mimetypes_file is relative path (using nonportable m!^/! instead of File::Spec::file_name_is_absolute), and if it is then it is used as relative to project. Does anyone use this feature to provide per-project mimetypes? Would perhaps using relative path as-is (i.e. relative to gitweb script) be better solution, and checking for gitweb.mimetypes repo configuration variable for per-repo relative to project if relative? -- Jakub Narebski Poland ```