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
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.,
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.4the same as plain old
- It would allow clients and servers to precicely advertise and understand each others’ level of WebP support.
- 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?
- something with the
profilesparameter, focused around (finalized!) features, rather than codec versions?
- A versioned WebP bitstream (!) and some new parameter for bitstream versions, e.g.
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.