[spiffy] [PATCH] Add mime type for json

[RvdH]

json is nowadays often used in web applications and web services, so I suggest adding it to the default list of mime types in Spiffy.

[sjamaan]

Thanks for taking the time to make a patch. However, I wonder how often people will be serving static files with a .json extension. That doesn't make much sense (json makes more sense as a data exchange format).

I'd prefer if the default extension->type mapping stayed as short and simple as possible. This ensures the spiffy library doesn't become too bloated with string data and doesn't make searching the list too slow. Adding just one more type to the default list won't be bad, but adding one type one hundred times will :) Of course, anyone's free to parameterize it in their own Spiffy setup.

Do you use static .json-files? Does it cause problems when they're served up as application/octet-stream?

I'm not 100% decided yet, but the advantage of adding it to the default list isn't clear to me yet. If there's a large body of software or emerging common practice out there that uses this extension, I wouldn't mind adding it.

[RvdH]

I understand your point. json is indeed used mostly as a data exchange format (as is xml for that matter). Not sure if the json mime type has a place in the Spiffy egg then. The only times I use it is if some cronjob generates static json files.

Still, the list looks kind of arbitrary now. Adding all mime types isn't a viable solution. I noticed many audio (e.g. mp3) and video (e.g. mpeg) formats are missing, as well as font formats (e.g. woff) and rss.

Not sure what "the right way" is. I will think about this.

[sjamaan]

Thanks for your understanding. It's true that it's pretty arbitrary; the current list is just what people have so far needed in practice. It would be great if there were clear "rules" of a sort to more easily decide what goes in and what doesn't.

I considered woff, but it wasn't necessary to add the type: it worked fine even with the "wrong" mime type. Browsers ignored the type, IIRC.

[RvdH]

Yeah, browsers are very liberal in what they accept. You can return application/octet-stream for about anything and it still works.

woff works with application/octet-stream as well, but at least Chrome displays a warning in its console: "Resource interpreted as font but transferred with MIME type application/octet-stream."

[sjamaan]

Currently web fonts are in flux, there are at least three formats out there that are accepted by browsers. I'd prefer to wait till things settle (if they ever do: people in control of patents are assholes, that's why there are a gazillion video formats) and then add one line for whatever font format wins this war.

The problem is the web is way too hype-driven. Every week a new format is invented and everyone scrambles to support it. I prefer to call bullshit on that. If a user needs to have obscure format of the week, they can: that's why it's a parameter :)

But for the long term, I'd like to have a clean rule for what gets added when. Right now I've focused on a minimum set of formats you'd need for very plain and simple sites. Multimedia formats are a rat-race I'd like to stay well away from right now. I think the current set of supported extensions/mime types is pretty stable and unlikely to be outdated soon (except, hopefully, the .ico one; that might disappear soon with IE6 and WinXP, and I'd be very happy to nuke it from the list).

[sjamaan]

For now I'm closing this issue. If it ever becomes strictly necessary to add text/json let me know, and I'd be happy to add it to the default list. In the meanwhile, you know how to override it for your own needs.

[RvdH]

Maybe it is better to support a mime.types-like configuration file, as Apache and nginx do. This also allows you to separate logic from configuration, keeping your code clean.

• Apache example: ​http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types
• nginx example: ​http://wiki.nginx.org/FullExample#mime_types

[evhan]

I think a better option would be to provide a full(er) mime type map in an egg (hopefully generated from an "official" list somewhere) and let people use that however they see fit. There's already mime-type-map for this, all that's needed is the big alist to plug in.

[sjamaan]

Replying to RvdH:

Maybe it is better to support a mime.types-like configuration file, as Apache and nginx do. This also allows you to separate logic from configuration, keeping your code clean.

This goes completely against everything Spiffy stands for. I don't think adding a pile of parsing code for a rigid configuration file syntax is helpful at all. Spiffy uses Scheme for everything in order to be lightweight, simple yet powerful.

However, feel free to write an egg which parses a file like that and puts it in the parameter. That's why Spiffy uses parameters everywhere: so that users can easily customise these things.