Jeremy Fitzhardinge wrote:
> 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.That's possible, but what would set this metadata? Neither the WUI nor the CLI have any information about the type other than by guessing. > 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? Because "text/plain" does not mean text -- it is treated by browsers as meaning "guess the type". (There is actually no MIME type that is reliably treated as text, which is unfortunate.) > 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. That would definitely be useful. I'll add a ticket for it. -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
