[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