Content negociation for WebP / JXR


#1

As you did for Brotli support, it would be great to support the content negotiation via the Accept header for WebP, JXR.

Accept: image/webp,image/apng,image/,/*;q=0.8
Accept: text/html, application/xhtml+xml, image/jxr, /

With KeyCDN, I don’t see a simple way to deliver different formats (webp or jpg) based on this header.
In this case, the Cache key is based on the Content-Type of the response.

Would it be possible to do this with a Vary:Accept header ?

Reference : https://www.igvita.com/2013/05/01/deploying-webp-via-accept-content-negotiation/.


#2

This is slightly different to the Brotli approach. I suggest to stick with the respective file extensions (.webp, .jxr, etc) to cache the correct version of a file. Caching based on the Content-Type header is not on our roadmap at the moment.


#3

I had a pretty long chat on support about this, and would love to see this feature implemented. Honestly, it’s just a bit silly that so many CDNs do not honor the Vary:Accept header. If KeyCDN could add this feature, they’d be ahead of the curve!


#4

Same here, lengthy exchanges with support. I desperately need “Vary: Accept” as well.

We serve JPEG or WEBP depending on browser support, on a single URL. KeyCDN ignoring the Vary header means that if a Chrome browser loads the image first, followed by Microsoft Edge, both will receive a WEBP, but only one of them will understand it.

The Vary header is part of the HTTP standard, namely RFC 7231, section 7.1.4:

An origin server might send Vary (…) to inform cache recipients that they MUST NOT use this response to satisfy a later request unless the later request has the same values for the listed fields as the original request (Section 4.1 of RFC7234). In other words, Vary expands the cache key required to match a new request to the stored cache entry.

Not supporting this header is a serious breaking of the standard that would deserve a big red warning in KeyCDN’s documentation; by ignoring the Vary header the CDN will serve the same content to browsers with different capabilities. The end result is a broken page.

I have to note that the Vary header is supported by pretty much every proxy implementation out there (for good reason).
I would love if KeyCDN could provide an ETA for this feature!

I can understand the fear, from a CDN perspective, that misuse of the Vary header by origin servers might lead to significantly lower HIT rates. But there are many reasonable use cases for this header, and content negotiation using Accept is one of them.

As far as I’m concerned, this feature is the last piece of awesomeness missing from KeyCDN.
But a piece big enough to consider another CDN…


#5

I agree with @sizeapi – it would be great to if KeyCDN would consider this.

In their own documentation, they describe why not using a Vary header can cause problems:

Yet they are not providing full support, just for Accept-Encoding.


#6

Still waiting for this, it’s the only thing keeping me from being perfectly content with KeyCDN. Please, please implement this so I don’t have to keep drooling over Cloudfront and MaxCDN :slight_smile:


#7

Any update from KeyCDN staff?


#8

I’ve been thinking about this a lot lately, and it seems it would have to be done very carefully so as to not impact performance too much. I’ve been using Cloudfront for one of my sites because they allow you to “whitelist” the Accept header.
That all works fine as a very basic approach for a site with a limited number of images/files. But the problem with that approach is that there are at least as many different Accept headers as there are browsers (a lot), and this means you’re caching a different object for every single one of those variations.
The only way this makes sense is if KeyCDN can build this specifically for certain image formats. In other words, if the request header “Accept” contains “image/webp” store one object (potentially a webp file), for everyone else, store the same object.
JPEG-XR would not be fun at all, since it would require parsing the user agent, and that’s less than reliable.
That’s my two cents, since I no longer need this feature (because I’ve used a different solution that works fine with KeyCDN).


#9

Thanks for the valuable feedback! It definitely makes sense to focus on specific keywords in the accept header to avoid harming the cache HIT ratio. Having more caching options on the accept header is on our roadmap.