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: