[tahoe-dev] File types and encodings

[David-Sarah Hopwood]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
Url : http://allmydata.org/pipermail/tahoe-dev/attachments/20100309/f8a4a952/attachment.pgp