More-specfic MIME types for images

Since 2011, Chromium has advertised Accept: image/webp. And while that Accept header has stayed constant, the WebP bitstream has evolved considerably; not all Chromiums support all WebPs.

This has caused Cloudinary a few problems. Currently, we must UA-sniff for Chromium 32+ in order to determine whether or not to send clients animated WebPs, instead of animated GIFs. And, frankly, we’re not doing enough to ensure that we’re only sending other sorts of WebPs to end users who can actually decode them – instead, we end up advising customers who experience compatibility problems with, for example, lossless WebPs, not to use the Cloudinary features which generate them.

The problem, here – varied bitstreams that all fall under the same nominal MIME type/subtype – has been addressed in the world of video with the codecs and profiles parameters. Recently, Mozilla even started adding specific AV1 encoder commit hashes to the codecs parameter, nailing down advertised support very specifically in order to keep up with the quickly-evolving format.

Could browsers start doing something similar for images?

WebP’s bitstream is not formally spec’d, and though the format is far more stable than it used to be, it’s changed quite a bit over the years – and there are no guarantees that it won’t change again. Servers and clients could start tacking codec versions onto WebP MIME types to advertise what they’ve encoded or what they’re decoding with, e.g., image/webp;codecs=libwebp.0.4.4.

Pros of this approach:

• in theory, it wouldn’t break anything, as non-codecs-aware sofware should ignore the parameter and treat image/webp;codecs=libwebp.0.4.4 the same as plain old image/webp.
• It would allow clients and servers to precicely advertise and understand each others’ level of WebP support.

Cons:

• It’s possible that in practice, this change could break some software which relies on exactly-matching MIME type strings?
• Could get complicated if there are ever alternative WebP libraries (like, e.g., libjpeg, mozjpeg, and jpeg-turbo).
• More fingerprinting data for evil trackers?

Harder/worse-seeming alternatives:

• something with the profiles parameter, focused around (finalized!) features, rather than codec versions? image/webp;profiles=lossless,animated?
• A versioned WebP bitstream (!) and some new parameter for bitstream versions, e.g. image/webp;version=1.0

I’ll note finally that while the lack of a way to differentiate between different flavors of a given MIME type is a particular problem for WebP right now, it’s not just a WebP problem; maybe a general mechanism could enable, say, smooth airthmatically-coded JPEG rollouts.

—
Eric Portis
Cloudinary

I’ve filed a Chromium bug about this issue here: https://bugs.chromium.org/p/chromium/issues/detail?id=854824

I think the standard procedure is that the IANA proposal for the MIME subtype is that the format should specify its own parameters. Unfortunately, it looks like .webp was never registered.

Tying a format to a specific implementation doesn’t seem great either; it smells like UA sniffing.

The cleanest way to do this is using a new media type; e.g., image/webp2' orimage/webp-animated` – especially if these formats aren’t compatible with some existing implementations, it needs to be easy to distinguish them and express preferences about each.

To address the current situation with WebP – this would be great. New UAs could then Accept: image/webp2,image/webp (or whatever) and only add differentiation for smart new UAs and servers, without breaking any existing things.