Wincent Colaiuta wrote:

quoted text
> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html