Mongrel users - Dec 2006 - [SURVEY] MIME types questions for Mongrel 1.0 RC1

I need people to answer a survey super quick for the next little release of
Mongrel.  Basically, nobody ever agrees on mime types, especially defaults,
which is why Mongrel has none and you set your own.  Sometimes people just
refuse to set their own and want Mongrel to do everything for them, but if that
happens then people will complain about the defaults.

Damned if I do, damned if I don''t.

So, let''s put this to the test:

1) Should Mongrel support a larger set of default mime types?
2) What should those defaults be?  Post a YAML file somewhere so I can compare
the various answers.
3) What should be the default mime type if a file doesn''t match?
3a) Where do you get this default?
4) Would anyone object to Mongrel moving the default mime type list into a YAML
file in the source tree that it loads?  **You''d still be able to
override like normal.**
5) If your favorite web server does it a particular way, do you actually think
this is the real standard or just what that web server does?
5a) Do you think this default could be improved on depending on the situation? 
Think development vs. production deployments.

Being the most vocal or ranting will get your votes discounted.  Keep it
rational and support it with external evidence, not rhetoric.  People can go
round in circles forever over something this idiotically simple.

I''m indifferent BTW, just annoyed at more work on mime types so
I''d like to put it to rest once and for all and make whatever seems to
be the most popular as the mongrel policy.

Finally, if nobody has an opinion then I''ll just leave it as-is in
order to get Mongrel 1.0 RC1 out.

Thanks for your time.

-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
http://mongrel.rubyforge.org/
http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.

On 12/6/06, Zed A. Shaw <zedshaw at zedshaw.com>
wrote:
>
>
> 1) Should Mongrel support a larger set of default mime types?

Yes.  The hardcore folks who have opinions will probably want to customize
theirs anyway, but the people who don''t care (probably the majority of
users) will appreciate having some "suitable" defaults.  (Dodging the
issue
of what''s "suitable" here; see below.)

2) What should those defaults be?  Post a YAML file somewhere so I
can
> compare the various answers.

require ''webrick/httputils''
require ''yaml''
puts YAML::dump(Hash[*WEBrick::HTTPUtils::DefaultMimeTypes.map {|k,v|
[".#{k}", v]}.zip.flatten])

3) What should be the default mime type if a file doesn''t match?


application/octet-stream

3a) Where do you get this default?


RFC 1521, by virtue of it being mentioned as the primary subtype.

4) Would anyone object to Mongrel moving the default mime type list into
a
> YAML file in the source tree that it loads?  **You''d still be able
to
> override like normal.**

No objection.

5) If your favorite web server does it a particular way, do you
actually
> think this is the real standard or just what that web server does?

Well, I wouldn''t say WEBrick is my favorite, it was just close at hand,
the
types seemed reasonable, and it''s a smaller set of types than, say,
Apache''s
default mime.types file.  I think getting consensus from the community on
the default set of types is totally a bikeshed issue waiting to happen;
you''ll have to end up drawing a line in the sand on the set of default
types, and a smaller set is probably better than a larger one.  Picking one
that''s already in the Ruby distro is maybe a cop-out, but then it gives
you
leverage to push back on differences and say that they''d have to be
accepted
into the standard library (bwah ha ha).

5a) Do you think this default could be improved on depending on
the
> situation?  Think development vs. production deployments.

I could see a larger set of defaults in a dev environment, or possibly
changing the default-if-not-found to "text/plain" or some other for
debugging purposes.

Cheers,
/Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-users/attachments/20061206/7c14249e/attachment.html

On 12/6/06, Zed A. Shaw <zedshaw at zedshaw.com>
wrote:
>
> I need people to answer a survey super quick for the next little release
> of Mongrel.  Basically, nobody ever agrees on mime types, especially
> defaults, which is why Mongrel has none and you set your own.  Sometimes
> people just refuse to set their own and want Mongrel to do everything for
> them, but if that happens then people will complain about the defaults.
>
> Damned if I do, damned if I don''t.
>
> So, let''s put this to the test:
>
> 1) Should Mongrel support a larger set of default mime types?

YES.

2) What should those defaults be?  Post a YAML file somewhere so I
can
> compare the various answers.

    Can''t we have MIME types be an intersection of Apache (2.2) and IIS
?

3) What should be the default mime type if a file doesn''t match?
> 3a) Where do you get this default?
> 4) Would anyone object to Mongrel moving the default mime type list into a
> YAML file in the source tree that it loads?  **You''d still be able
to
> override like normal.**
> 5) If your favorite web server does it a particular way, do you actually
> think this is the real standard or just what that web server does?
> 5a) Do you think this default could be improved on depending on the
> situation?  Think development vs. production deployments.
>

Thank you,

BR,
~A
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-users/attachments/20061206/e82c30cf/attachment.html

> 
> 1) Should Mongrel support a larger set of default mime types?
Yes, please!
> 2) What should those defaults be?  
I''m fine with Apache''s default list.
> 3) What should be the default mime type if a file doesn''t match?
application/occtect-stream? But I really don''t care.
> 3a) Where do you get this default?
> 4) Would anyone object to Mongrel moving the default mime type 
> list into a YAML file in the source tree that it loads?
 > **You''d still be able to override like normal.**

no, I would appreciate like such default behavior.
> 5) If your favorite web server does it a particular way, 
> do you actually think this is the real standard or just what that web
server does?
No idea if Apache''s settings are the real standard, in doubt it is 
reasonable.
> 5a) Do you think this default could be improved on depending 
> on the situation?  Think development vs. production deployments.
> 
no opinion here.

Generally I think that a small default set for 
html/css/javascript/xml/zip/img/png&co is really useful.
> Thanks for your time.
> 
Jonathan

-- 
Jonathan Weiss
http://blog.innerewut.de

On Dec 6, 2006, at 2:19 PM, Zed A. Shaw wrote:
> I need people to answer a survey super quick for the next little  
> release of Mongrel.  Basically, nobody ever agrees on mime types,  
> especially defaults, which is why Mongrel has none and you set your  
> own.  Sometimes people just refuse to set their own and want  
> Mongrel to do everything for them, but if that happens then people  
> will complain about the defaults.
>
> Damned if I do, damned if I don''t.
>
> So, let''s put this to the test:
>
> 1) Should Mongrel support a larger set of default mime types?
> 2) What should those defaults be?  Post a YAML file somewhere so I  
> can compare the various answers.
> 3) What should be the default mime type if a file doesn''t match?
> 3a) Where do you get this default?
> 4) Would anyone object to Mongrel moving the default mime type list  
> into a YAML file in the source tree that it loads?  **You''d still
> be able to override like normal.**
> 5) If your favorite web server does it a particular way, do you  
> actually think this is the real standard or just what that web  
> server does?
> 5a) Do you think this default could be improved on depending on the  
> situation?  Think development vs. production deployments.
>
> Being the most vocal or ranting will get your votes discounted.   
> Keep it rational and support it with external evidence, not  
> rhetoric.  People can go round in circles forever over something  
> this idiotically simple.
>
> I''m indifferent BTW, just annoyed at more work on mime types so
I''d
> like to put it to rest once and for all and make whatever seems to  
> be the most popular as the mongrel policy.
>
> Finally, if nobody has an opinion then I''ll just leave it as-is in
> order to get Mongrel 1.0 RC1 out.
>
> Thanks for your time.
I''m indifferent as well from the userside of things but I suspect  
that if you did support a larger set it could make your support life  
easier.

If you want something that might be "quick and easy" (and I put that  
in quotes because I''m talking out of my ass and it might not be easy  
outside of hey-here-is-a-file) I''ve just added to apache''s
default
etc/mime.types over the last 2.5 years of textdrive, and if that just  
copied over and put into a mimetypes.yml

A fine default is application/octet-stream  or plain text.

Regards, Jason

> So, let''s put this to the test:
>
> 1) Should Mongrel support a larger set of default mime types?
I''m strongly in favor of this. Especially for core defaults like xml,  
atom, and rss. It would mean that Rails page caching would Just Work  
even for these common caching types.
> 2) What should those defaults be?  Post a YAML file somewhere so I  
> can compare the various answers.
existing +
application/atom+xml
application/rss+xml
application/xml
text/calendar
text/csv
application/x-yaml

...that also just happens to correspond with the default Mime types  
that Rails ships with ;)
> 3) What should be the default mime type if a file doesn''t match?
application/octet-stream. That causes browsers to force the file to  
be downloaded. Which is most likely what you''ll want since unknown  
file types are usually of a binary format. Like flash/wmp/quicktime  
movies, PDFs, etc.
> 3a) Where do you get this default?
Preferably it would just ship in Mongrel, but be override-able by -- 
default-mime-type
> 4) Would anyone object to Mongrel moving the default mime type list  
> into a YAML file in the source tree that it loads?  **You''d still
> be able to override like normal.**
+1
> 5) If your favorite web server does it a particular way, do you  
> actually think this is the real standard or just what that web  
> server does?
There are no "real" standards on this as far as I know. Just defacto  
standards (like application/octet-stream for unknown types).
> 5a) Do you think this default could be improved on depending on the  
> situation?  Think development vs. production deployments.
I''d prefer consistent behavior from the web server across the  
environments. For the same reason that I tend to want to run the same  
version of Apache, lighttpd, MySQL, and Ruby between development and  
production.
--
David Heinemeier Hansson


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1940 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/mongrel-users/attachments/20061206/ead955a7/attachment-0001.bin

On Dec 6, 2006, at 2:19 PM, Zed A. Shaw wrote:
> 1) Should Mongrel support a larger set of default mime types?
Yes I think this would be very useful. In production most of the  
extra mime types are not needed because a front end web server  
handles most filetypes. But in dev mode its nice to use plain mongrel  
and still be able to serve different media types and such.
> 2) What should those defaults be?  Post a YAML file somewhere so I  
> can compare the various answers.
Here is the default set of mime types for nginx. I have been running  
with these on a lot of sites and haven''t had to add one yet

http://pastie.caboo.se/26234
> 3) What should be the default mime type if a file doesn''t match?
application/octet-stream

> 3a) Where do you get this default?
it  is the default for nginx and lighty.
> 4) Would anyone object to Mongrel moving the default mime type list  
> into a YAML file in the source tree that it loads?  **You''d still
> be able to override like normal.**
please go for it.
> 5) If your favorite web server does it a particular way, do you  
> actually think this is the real standard or just what that web  
> server does?
The list of mime types linked above has served me well on close to  
100 installs without needing additions.  I am not certain if it  
varies compared to whatever is considered standard. I don''t know what  
the authority on mime types for webservers is.

> 5a) Do you think this default could be improved on depending on the  
> situation?  Think development vs. production deployments.
	
I am not really sure. I think application/octet-stream is good  
default as long as it can be over-ridden then it should meet  
everyones needs.


Thanks Zed-

-- Ezra Zygmuntowicz 
-- Lead Rails Evangelist
-- ez at engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)

On 12/6/06, Ezra Zygmuntowicz <ezmobius at gmail.com>
wrote:
>
>
> On Dec 6, 2006, at 2:19 PM, Zed A. Shaw wrote:
>
> > 1) Should Mongrel support a larger set of default mime types?

I think this would be great.  Just last week I added a mimes.yml file to my
application.  Seems like adding a few more defaults, as long as they are
overridable would mean one less thing for my small brain to need to learn.
~Michael F
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-users/attachments/20061206/2ce52006/attachment.html

On 12/6/06, Zed A. Shaw <zedshaw at zedshaw.com>
wrote:
> I need people to answer a survey super quick for the next little release of
Mongrel.  Basically, nobody ever agrees on mime types, especially defaults,
which is why Mongrel has none and you set your own.  Sometimes people just
refuse to set their own and want Mongrel to do everything for them, but if that
happens then people will complain about the defaults.
>
> Damned if I do, damned if I don''t.
>
> So, let''s put this to the test:
>
> 1) Should Mongrel support a larger set of default mime types?
No-ish.  I say no for a similar reason that Nick said yes. If people
need some weird mime type for files then they should be able to add
those but I think the majority of people just need the basics. Perhaps
there are a few other types that would be nice to have in the list as
well but I don''t see the point in having a large list when so many
people will never use it. That said, if mongrel adopts the Apache list
(or something like it) I won''t belly ache.
> 2) What should those defaults be?  Post a YAML file somewhere so I can
compare the various answers.
> 3) What should be the default mime type if a file doesn''t match?
application/octet-stream
> 3a) Where do you get this default?
RFC 1521, by virtue of it being mentioned as the primary subtype. -
Quoted from Nick
> 4) Would anyone object to Mongrel moving the default mime type list into a
YAML file in the source tree that it loads?  **You''d still be able to
override like normal.**
no objection. i like the idea.
> 5) If your favorite web server does it a particular way, do you actually
think this is the real standard or just what that web server does?
My favorite web servers are currently mongrel and nginx. I am happy
with the way mongrel does things for the most part. I am not a fan of
nginx''s obvious preference of certain linux packaging mimes in their
list but it doesn''t bother me either.
> 5a) Do you think this default could be improved on depending on the
situation?  Think development vs. production deployments.
I don''t see a real need to make them different. If I need to change
something, I will depending on the situation anyways.

Zed, personally I don''t think you need to worry too much about people
not liking mongrels mime types. If someone needs to add/remove/edit
anything in the list, they will and chances are that most people won''t
need to. If there comes a time when a mime type gains popularity, then
sure, add it but I don''t think you should bother yourself too much in
making every niche group happy and having a huge list.

Kyle Kochis

David Heinemeier Hansson wrote:
>> So, let''s put this to the test:
>>
>> 1) Should Mongrel support a larger set of default mime types?
> 
> I''m strongly in favor of this. Especially for core defaults like
xml,
> atom, and rss. It would mean that Rails page caching would Just Work 
> even for these common caching types.
Could you explain this? Mongrel is very unlikely to serve cached pages. 
That''s usually handled by apache/lighty. I ran into this the other day 
and had to adjust my apache rewrite rules to look for cached .xml files 
rather than just .html files.

Jeroen

On 12/6/06, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
[snip]
>
> 1) Should Mongrel support a larger set of default mime types?
Yes, I agree with Nick Seiger on extend it using WEBrick default mime
types which are similar to those Ezra pointed.

Regarding Rails caching (DHH), still don''t get it... Shouldn''t
Mongrel
also serve the cached query even if his extension differ from .html?
or that should be done by the Parent webserver?
> 2) What should those defaults be?  Post a YAML file somewhere so I can
compare the various answers.
WEBrick default mime types looks fine. the nginx types just add a few
definitions for octet-stream, like deb packages, iso and msi
installers, including executables. So guess that will fallback into
the "default" mime type for unknown elements.
> 3) What should be the default mime type if a file doesn''t match?
appplication/octet-stream
> 3a) Where do you get this default?
Most of the webservers fall back to that. Some bizarre ones defaults
to text/plain but guess that is not suitable (what if the unknown type
is actually a binary file).
> 4) Would anyone object to Mongrel moving the default mime type list into a
YAML file in the source tree that it loads?  **You''d still be able to
override like normal.**
Guess that will be more maintainable, right? not hard coded into the
code but loadable.

Adding mime types (using my one mime.conf file) should ADD
functionality and could override the defaults, but not remove them
(something to check when doing merge!)
> 5) If your favorite web server does it a particular way, do you actually
think this is the real standard or just what that web server does?
> 5a) Do you think this default could be improved on depending on the
situation?  Think development vs. production deployments.
>
I do similar things like Nick (set the default to text/plain in
development) for debugging purposes.

Support the minimal set, and let the user (us) add the specific mime
requirements instead of maintaining we-own-all-the-mimes-in-the-world
approach (apache?)
> Being the most vocal or ranting will get your votes discounted.  Keep it
rational and support it with external evidence, not rhetoric.  People can go
round in circles forever over something this idiotically simple.
>
Excuse the bits of rhetoric comments in this message :-)
> I''m indifferent BTW, just annoyed at more work on mime types so
I''d like to put it to rest once and for all and make whatever seems to
be the most popular as the mongrel policy.
>
I like your approach of "policy", when you draw the line, you stick to
it ;-)
> Finally, if nobody has an opinion then I''ll just leave it as-is in
order to get Mongrel 1.0 RC1 out.
>
Excellent!, thought about mswin32 builds put on the pre release gem repository?
> Thanks for your time.
>
Thanks to you Zed,


-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

Hi,

On 6-Dec-06, at 5:19 PM, Zed A. Shaw wrote:
>
> 1) Should Mongrel support a larger set of default mime types?
I think so, as long as it is easy to both add new mime types and  
override the whole thing. At the start of a project I don''t really  
want to be worrying about configuring stuff like mime types, and I  
can''t really imagine who would be wanting to worry about stuff like  
that early on. After a bit of development this can become more  
''interesting'' to think about, at which point tweaking or
overriding
would be necessary.
> 2) What should those defaults be?  Post a YAML file somewhere so I  
> can compare the various answers.
Something correct, and by that I mean something that works. Using  
Apache''s would be a good shot at something that works.
> 3) What should be the default mime type if a file doesn''t match?
application/octet-stream
> 3a) Where do you get this default?
Well, my understanding is that this is meant to be the default. But  
in truth, it is the only thing that makes sense in practice... I  
think trying to figure out something clever to do in the default  
situation is a really bad idea.
> 4) Would anyone object to Mongrel moving the default mime type list  
> into a YAML file in the source tree that it loads?  **You''d still
> be able to override like normal.**
No.... Okay, why might we object?
> 5) If your favorite web server does it a particular way, do you  
> actually think this is the real standard or just what that web  
> server does?
:-) Well I don''t know about favourites, but practically speaking,  
whatever Apache does might as well be a standard.
> 5a) Do you think this default could be improved on depending on the  
> situation?  Think development vs. production deployments.
No. Please don''t do that! I really don''t like behaviour,
especially
behaviour that affects a user, changing when switching from  
development to production.
>
> Being the most vocal or ranting will get your votes discounted.   
> Keep it rational and support it with external evidence, not  
> rhetoric.  People can go round in circles forever over something  
> this idiotically simple.
>
> I''m indifferent BTW, just annoyed at more work on mime types so
I''d
> like to put it to rest once and for all and make whatever seems to  
> be the most popular as the mongrel policy.
>
> Finally, if nobody has an opinion then I''ll just leave it as-is in
> order to get Mongrel 1.0 RC1 out.
That''s fine with me.
>
> Thanks for your time.
>
> -- 
> Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
> http://www.zedshaw.com/
> http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
> http://mongrel.rubyforge.org/
> http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
----
Bob Hutchison                  -- blogs at <http://www.recursive.ca/ 
hutch/>
Recursive Design Inc.          -- <http://www.recursive.ca/>
Raconteur                      -- <http://www.raconteur.info/>
xampl for Ruby                 -- <http://rubyforge.org/projects/xampl/>

On Dec 06, 2006, at 17:19 , Zed A. Shaw wrote:
> 1) Should Mongrel support a larger set of default mime types?
Absolutely.
> 2) What should those defaults be?  Post a YAML file somewhere so I  
> can compare the various answers.
After reading through the previous posts from last night,
My list matches Ezra''s at http://pastie.caboo.se/26234
> 3) What should be the default mime type if a file doesn''t match?
application/octet-stream
> 3a) Where do you get this default?
Default for Lighttpd
> 4) Would anyone object to Mongrel moving the default mime type list  
> into a YAML file in the source tree that it loads?  **You''d still
> be able to override like normal.**
Sounds like a great idea, this also would allow for people to  
override the defaults for an entire server (shared hosting  
environments).
> 5) If your favorite web server does it a particular way, do you  
> actually think this is the real standard or just what that web  
> server does?
Apache is pretty much the best "standard" to follow in this area I  
believe.
> 5a) Do you think this default could be improved on depending on the  
> situation?  Think development vs. production deployments.
This would be useful in my opinion.

	~Wayne

On Dec 06, 2006, at 18:06 , David Heinemeier Hansson
wrote:
> I''m strongly in favor of this. Especially for core defaults like  
> xml, atom, and rss. It would mean that Rails page caching would  
> Just Work even for these common caching types.
I agree with your point however could you elaborate on the last  
sentence a little bit?

	~Wayne

>>> So, let''s put this to the test:
>>>
>>> 1) Should Mongrel support a larger set of default mime types?
>>
>> I''m strongly in favor of this. Especially for core defaults
like xml,
>> atom, and rss. It would mean that Rails page caching would Just Work
>> even for these common caching types.
>
> Could you explain this? Mongrel is very unlikely to serve cached  
> pages.
> That''s usually handled by apache/lighty. I ran into this the other
day
> and had to adjust my apache rewrite rules to look for cached .xml  
> files
> rather than just .html files.
There are plenty of situations where the load requirements do not  
dictate involving another web server. It''d be nice if Mongrel was  
feature-wise capable of standing on its own. Mongrel is still capable  
of serving hundreds of static files per second on most machines.  
That''s plenty for a large array of applications, including  
predominately internal ones.
--
David Heinemeier Hansson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1940 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/mongrel-users/attachments/20061207/ddbe5c9d/attachment.bin

David Heinemeier Hansson wrote:
>>>> So, let''s put this to the test:
>>>>
>>>> 1) Should Mongrel support a larger set of default mime types?
>>>
>>> I''m strongly in favor of this. Especially for core
defaults like xml,
>>> atom, and rss. It would mean that Rails page caching would Just
Work
>>> even for these common caching types.
>>
>> Could you explain this? Mongrel is very unlikely to serve cached pages.
>> That''s usually handled by apache/lighty. I ran into this the
other day
>> and had to adjust my apache rewrite rules to look for cached .xml files
>> rather than just .html files.
> 
> There are plenty of situations where the load requirements do not 
> dictate involving another web server. It''d be nice if Mongrel was 
> feature-wise capable of standing on its own. Mongrel is still capable of 
> serving hundreds of static files per second on most machines.
That''s
> plenty for a large array of applications, including predominately 
> internal ones.
Okay that makes sense then.

I have never tried page caching with mongrel only. I know that on apache 
I need to add mod_rewrite rules for each mime-type/extension (or maybe 
there''s a smarter way..) If I use the default rewrite rules a cached 
version of public/somecontroller/index.xml will never get served for 
instance, because it''s looking for index.html.

You''re saying page caching on a mongrel only setup will just work as 
long as the mime-types are properly configured?

Oh, and just out of curiosity, does 37 signals use mongrel or still lighty?

Jeroen

> You''re saying page caching on a mongrel only setup will just work
as
> long as the mime-types are properly configured?
Yes. The approach is the same as with lighttpd and Apache. First the  
web server looks on the file system, if it doesn''t find it,
it''ll
redirect to the 404 handler, which is Rails.

So if you have /products/5.xml in public, the web server will always  
serve that rather than let Rails try. Thus, we need to make sure that  
the file is then returned with application/xml mime type.
> Oh, and just out of curiosity, does 37 signals use mongrel or still  
> lighty?
Both. We also use Apache. But newer deployments are happening on  
Mongrel.
--
David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1940 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/mongrel-users/attachments/20061207/ec79bc16/attachment.bin

On 12/6/06, Zed A. Shaw <zedshaw at zedshaw.com>
wrote:
> I need people to answer a survey super quick for the next little release of
Mongrel.  Basically, nobody ever agrees on mime types, especially defaults,
which is why Mongrel has none and you set your own.  Sometimes people just
refuse to set their own and want Mongrel to do everything for them, but if that
happens then people will complain about the defaults.
>
> Damned if I do, damned if I don''t.
>
> So, let''s put this to the test:
>
> 1) Should Mongrel support a larger set of default mime types?

Yes.  And I like the idea of a separate yaml file for them.