[tahoe-dev] File types and encodings

Jeremy Fitzhardinge jeremy at goop.org
Tue Mar 9 09:53:27 PST 2010


I've noticed that the webapi tends to return fairly arbitrary 
Content-types headers when fetching files; it seems to use its own 
internal extension to mime type table, and if that fails it defaults to 
text/plain.

Given that a directory supports arbitrary metadata for file entries, it 
would seem like an obvious extension to define a metadata tag for mime 
type ("content-type" or "mime-type"), and have the webapi return that as 
the content mime type.

As a fallback, using a heuristic table to derive the type is useful for 
well-known types, but defaulting to text/plain if that fails seems 
pretty odd.  Why not default to application/octet-stream?  A 200MB .m4v 
file is definitely not text, and anything trying to treat it as such 
will get a shock.

And if we're doing something with types, then we may as well something 
to deal with encodings, so that we can serve up pre-compressed data as 
compressed.

Thoughts?

     J


More information about the tahoe-dev mailing list