List for cgit developers and users
 help / color / mirror / Atom feed
* mime types
@ 2011-06-22 19:10 mailings
  2011-06-22 21:01 ` hjemli
  0 siblings, 1 reply; 5+ messages in thread
From: mailings @ 2011-06-22 19:10 UTC (permalink / raw)


Hi

Instead of hardcoding the mime types cgit knows about, why not read
/etc/mime.types when a mime type is needed?

grtz

-- 
Ferry Huberts




^ permalink raw reply	[flat|nested] 5+ messages in thread

* mime types
  2011-06-22 19:10 mime types mailings
@ 2011-06-22 21:01 ` hjemli
  2011-06-22 21:22   ` mailings
  0 siblings, 1 reply; 5+ messages in thread
From: hjemli @ 2011-06-22 21:01 UTC (permalink / raw)


On Wed, Jun 22, 2011 at 21:10, Ferry Huberts <mailings at hupie.com> wrote:
> Instead of hardcoding the mime types cgit knows about, why not read
> /etc/mime.types when a mime type is needed?

Yeah, an option to specify the path to a (httpd style) mime.types file
and then looking into this file when a mimetype lookup is needed (i.e.
in ui-plain.c) sounds like a good idea.

--
larsh




^ permalink raw reply	[flat|nested] 5+ messages in thread

* mime types
  2011-06-22 21:01 ` hjemli
@ 2011-06-22 21:22   ` mailings
  2011-06-22 21:55     ` hjemli
  0 siblings, 1 reply; 5+ messages in thread
From: mailings @ 2011-06-22 21:22 UTC (permalink / raw)


On 06/22/2011 11:01 PM, Lars Hjemli wrote:
> On Wed, Jun 22, 2011 at 21:10, Ferry Huberts <mailings at hupie.com> wrote:
>> Instead of hardcoding the mime types cgit knows about, why not read
>> /etc/mime.types when a mime type is needed?
> 
> Yeah, an option to specify the path to a (httpd style) mime.types file
> and then looking into this file when a mimetype lookup is needed (i.e.
> in ui-plain.c) sounds like a good idea.

already working on it :-)

found ui-plain.c::print_object to change


With the httpd style I hope you mean the same format as /etc/mime.types?
My /etc/mime.types is provided by mailcap on F15 and CentOS/RHEL 5
It's format is very simple:
- comments are empty lines or lines starting with a #
- other lines are: mimetype [extension]+


I propose a new parameter called mime-types with a default of
/etc/mime.types

-- 
Ferry Huberts




^ permalink raw reply	[flat|nested] 5+ messages in thread

* mime types
  2011-06-22 21:22   ` mailings
@ 2011-06-22 21:55     ` hjemli
  2011-06-22 22:02       ` mailings
  0 siblings, 1 reply; 5+ messages in thread
From: hjemli @ 2011-06-22 21:55 UTC (permalink / raw)


On Wed, Jun 22, 2011 at 23:22, Ferry Huberts <mailings at hupie.com> wrote:
> On 06/22/2011 11:01 PM, Lars Hjemli wrote:
>> On Wed, Jun 22, 2011 at 21:10, Ferry Huberts <mailings at hupie.com> wrote:
>>> Instead of hardcoding the mime types cgit knows about, why not read
>>> /etc/mime.types when a mime type is needed?
>>
>> Yeah, an option to specify the path to a (httpd style) mime.types file
>> and then looking into this file when a mimetype lookup is needed (i.e.
>> in ui-plain.c) sounds like a good idea.
>
> already working on it :-)

Great.

> With the httpd style I hope you mean the same format as /etc/mime.types?

I think so. See below...

> My /etc/mime.types is provided by mailcap on F15 and CentOS/RHEL 5
> It's format is very simple:
> - comments are empty lines or lines starting with a #
> - other lines are: mimetype [extension]+
>

On my box (slackware 13), there's no /etc/mime.types but there's
/etc/httpd/mime.types which seems to match your description [1]. But
`man mime.types` documents a different format used by CUPS, which
seems to be much more complex [2]. We probably don't want to support
the latter variant.

> I propose a new parameter called mime-types with a default of
> /etc/mime.types

I don't think the parameter should have a default value - not everyone
agree that plain-view should return the "correct" mimetypes for blobs
(due to security _and_ philosophy), hence the use of hardcoded
"plain/text" and "application/octet-stream" when no (matching)
mimetype-mapping is specified in cgitrc.

Also, since we already have the option 'mimetype.<ext>', I propose the
name 'mimetype-file' for this new option.

-- 
larsh

[1] $ head -20 /etc/httpd/mime.types
# This file maps Internet media types to unique file extension(s).
# Although created for httpd, this file is used by many software systems
# and has been placed in the public domain for unlimited redisribution.
#
# The table below contains both registered and (common) unregistered types.
# A type that has no unique extension can be ignored -- they are listed
# here to guide configurations toward known types and to make it easier to
# identify "new" types.  File extensions are also commonly used to indicate
# content languages and encodings, so choose them carefully.
#
# Internet media types should be registered as described in RFC 4288.
# The registry is at <http://www.iana.org/assignments/media-types/>.
#
# MIME type					Extensions
# application/3gpp-ims+xml
# application/activemessage
application/andrew-inset			ez
# application/applefile
application/applixware				aw
application/atom+xml				atom

[2] $ man mime.types|cat
mime.types(5)                     Apple Inc.                     mime.types(5)

NAME
       mime.types - mime type description file for cups

DESCRIPTION
       The mime.types file defines the recognized file types.

       Additional  file  types  can  be added to mime.types or (preferably) in
       additional files in the CUPS configuration directory with the extension
       ".types".

       Each  line  in  the  mime.types file is a comment, blank, or rule line.
       Comment lines start with the # character. Rule  lines  start  with  the
       MIME type name and are optionally followed by a series of file recogni?
       tion rules that are used to automatically identify print and web files:

           super/type rule [ ... ruleN]
       The rules may be grouped using parenthesis, joined using "+" for a log?
       ical AND and "," or whitespace for a logical OR, and negated using "!".

RULES
       Rules  take  two  forms  - a filename extension by itself and functions
       with test values inside parenthesis. The following functions are avail?
       able:

       match("pattern")
            Pattern match on filename

       ascii(offset,length)
            True if bytes are valid printable ASCII (CR, NL, TAB, BS, 32-126)

       printable(offset,length)
            True  if bytes are printable 8-bit chars (CR, NL, TAB, BS, 32-126,
            128-254)

       string(offset,"string")
            True if bytes are identical to string

       istring(offset,"string")
            True if a case-insensitive comparison of the bytes is identical

       char(offset,value)
            True if byte is identical

       short(offset,value)
            True if 16-bit integer is identical

       int(offset,value)
            True if 32-bit integer is identical

       locale("string")
            True if current locale matches string

       contains(offset,range,"string")
            True if the range contains the string

STRING CONSTANTS
       String constants can be specified inside quotes ("") for  strings  con?
       taining whitespace and angle brackets (<>) for hexadecimal strings.

SEE ALSO
       classes.conf(5),   cupsd(8),   cupsd.conf(5),   mime.convs(5),   print?
       ers.conf(5),
       http://localhost:631/help

COPYRIGHT
       Copyright 2007 by Apple Inc.

12 February 2006          Common UNIX Printing System            mime.types(5)




^ permalink raw reply	[flat|nested] 5+ messages in thread

* mime types
  2011-06-22 21:55     ` hjemli
@ 2011-06-22 22:02       ` mailings
  0 siblings, 0 replies; 5+ messages in thread
From: mailings @ 2011-06-22 22:02 UTC (permalink / raw)


On 06/22/2011 11:55 PM, Lars Hjemli wrote:
> On my box (slackware 13), there's no /etc/mime.types but there's
> /etc/httpd/mime.types which seems to match your description [1]. But
> `man mime.types` documents a different format used by CUPS, which
> seems to be much more complex [2]. We probably don't want to support
> the latter variant.
> 

agreed

>> I propose a new parameter called mime-types with a default of
>> /etc/mime.types
> 
> I don't think the parameter should have a default value - not everyone
> agree that plain-view should return the "correct" mimetypes for blobs
> (due to security _and_ philosophy), hence the use of hardcoded
> "plain/text" and "application/octet-stream" when no (matching)
> mimetype-mapping is specified in cgitrc.
> 
> Also, since we already have the option 'mimetype.<ext>', I propose the
> name 'mimetype-file' for this new option.
> 

ok

I will first start to implement without the parameter anyway.

-- 
Ferry Huberts




^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2011-06-22 22:02 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-22 19:10 mime types mailings
2011-06-22 21:01 ` hjemli
2011-06-22 21:22   ` mailings
2011-06-22 21:55     ` hjemli
2011-06-22 22:02       ` mailings

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).