3 ms·

From the article: "To emit html that references either a JPEG or a WebP depending on the browser, you need some way that the server can tell whether the browse

by cdmckay 12y ago

From the article: "To emit html that references either a JPEG or a WebP depending on the browser, you need some way that the server can tell whether the browser supports WebP. Because this feature is so valuable, there is a standard way of indicating support for it: include image/webp in the Accept header. Unfortunately this doesn't quite work in practice. For example, Chrome v36 on iOS broke support for WebP images outside of data:// urls but was still sending Accept: image/webp. Similarly, Opera added image/webp to their Accept header before they supported WebP lossless. And no one indicates in their Accept whether they support animated WebP."

Dylan16807 12y ago
Well those are dumb problems but sniffing UA doesn't really fix them. You'll still have clients suddenly broken. ....what the heck is an animated WebP
- cbr 12y ago
  what the heck is an animated WebP A drop in improvement for animated GIF: https://developers.google.com/speed/webp/faq#why_should_i_use_animated_webp https://developers.google.com/speed/webp/faq#why_should_i_us...
  - Dylan16807 12y ago
    That doesn't explain what it actually is, though. How it does multiple frames. It does clarify that it's at least not quite WebM, but it doesn't explain how far away it is.
myhf 12y ago
That's a good argument for the image host to sniff the UA string in the course of content negotiation. It's not a good argument for crafting html that bypasses content negotiation.
- cbr 12y ago
  The problem with solving this in content negotiation is that breaks proxy caches. If you serve uncachable html that references either jpg or webp then you can serve those resources as "Cache-Control: public", and if you include a content hash or versioning in the URL then you can send a long cache lifetime. If you use the Accept or User-Agent headers to choose what image format to send them you need to issue a Vary header, and basically all proxy caches will treat that as uncachable. There's some progress with "Vary: Accept" support, but "Vary: User-Agent" is probably never going to be supported.
jameshart 12y ago
That argument's pretty weak. A bug in chrome v36 on iOS, and a limitation on the forms of webp you can serve if you want them to work in Opera, are not really good enough for me to dismiss the value of Accept headers. Why are you bothered whether the browser might or might not accept animated WebP? You're trying to send a static picture of a kitten. And likewise, Opera's lack of support for lossless? Not relevant to your use case.

by cdmckay 12y ago

Dylan16807 12y ago

Well those are dumb problems but sniffing UA doesn't really fix them. You'll still have clients suddenly broken. ....what the heck is an animated WebP

cbr 12y ago
what the heck is an animated WebP A drop in improvement for animated GIF: https://developers.google.com/speed/webp/faq#why_should_i_use_animated_webp https://developers.google.com/speed/webp/faq#why_should_i_us...
- Dylan16807 12y ago
  That doesn't explain what it actually is, though. How it does multiple frames. It does clarify that it's at least not quite WebM, but it doesn't explain how far away it is.

myhf 12y ago

That's a good argument for the image host to sniff the UA string in the course of content negotiation. It's not a good argument for crafting html that bypasses content negotiation.

cbr 12y ago
The problem with solving this in content negotiation is that breaks proxy caches. If you serve uncachable html that references either jpg or webp then you can serve those resources as "Cache-Control: public", and if you include a content hash or versioning in the URL then you can send a long cache lifetime. If you use the Accept or User-Agent headers to choose what image format to send them you need to issue a Vary header, and basically all proxy caches will treat that as uncachable. There's some progress with "Vary: Accept" support, but "Vary: User-Agent" is probably never going to be supported.

jameshart 12y ago

That argument's pretty weak. A bug in chrome v36 on iOS, and a limitation on the forms of webp you can serve if you want them to work in Opera, are not really good enough for me to dismiss the value of Accept headers. Why are you bothered whether the browser might or might not accept animated WebP? You're trying to send a static picture of a kitten. And likewise, Opera's lack of support for lossless? Not relevant to your use case.