locked
Not getting Brotli compression from Azure CDN RRS feed

  • Question

  • I'm using Azure CDN (Standard Verizon). 

    This should support Brotli compression, according to the documentation here: https://docs.microsoft.com/en-us/azure/cdn/cdn-improve-performance

    I have compression turned on on the CDN endpoint.

    If I send a request to the CDN with the header "Accept-Encoding: br", it does not respond with a Brotli compressed response. (If I send the header "Accept-Encoding: gzip", it responds with a gzip compressed response as expected.)

    The requested file is about a 1.5 kilobytes, and sent with mime-type "application/javascript", so it's not too small or too big to be compressed according to the documentation, and the mime-type is in the list of types that should be compressed in the CDN settings.

    I have now also set up brotli compression on the origin (my server). So it responds with brotli compressed responses on demand. This does not change the behavior of the CDN, it still responds with uncompressed responses.

    If I purge the file on the CDN, and then request the file from the CDN, the first response from the CDN is Brotli compressed, but the subsequent requests are not. It's as if the CDN is decompressing the file, caching it decompressed, and refusing to serve it compressed from there on.

    How can I get this CDN to serve Brotli compressed files as advertised?

    Tuesday, April 14, 2020 7:32 PM

Answers

  • Hi Lars, 

    Unfortunately it would appear the article you provided is incorrect. Verizon CDN do not yet support brotli compression at the edge. It is able to cache and serve the asset in brotli format, if pre-compressed by the origin. For other types of compression the edges servers can handle the compression. The ability to set compression algorithm preference is not a feature that is available at this time.

    Let me know if you have any further questions. 

    Regards, 

    Msrini

    Wednesday, April 15, 2020 9:50 AM

All replies

  • Hi Lars, 

    Unfortunately it would appear the article you provided is incorrect. Verizon CDN do not yet support brotli compression at the edge. It is able to cache and serve the asset in brotli format, if pre-compressed by the origin. For other types of compression the edges servers can handle the compression. The ability to set compression algorithm preference is not a feature that is available at this time.

    Let me know if you have any further questions. 

    Regards, 

    Msrini

    Wednesday, April 15, 2020 9:50 AM
  • Thanks msrini,

    You say: "It is able to cache and serve the asset in brotli format, if pre-compressed by the origin." I haven't been able to get it to do this. My origin can serve documents with brotli compression. If I purge the file, and make a request with "Accept-Encoding: br" to the CDN, the first request returns a brotli-compressed response, and the next response is uncompressed.

    How do I get it to cache the brotli-compressed response from my origin? Could there be a header from the origin that is preventing this? Below is a trace of the response headers for some requests:

    1) First request to CDN after purge, produces brotli compressed response (presumably forwarded from origin):

    Content-Encoding            br                                                                                         
    Access-Control-Allow-Origin *                                                                                           
    Vary                        Accept-Encoding
    Accept-Ranges               bytes
    Content-Length              1732
    Cache-Control               max-age=604800
    Content-Type                application/javascript
    Date                        Tue, 14 Apr 2020 18:25:34 GMT
    Expires                     Tue, 21 Apr 2020 18:25:34 GMT
    ETag                        "1d60438744ea549"
    Last-Modified               Fri, 27 Mar 2020 13:05:57 GMT
    Set-Cookie                  <cookie-data>
    Server                      Microsoft-IIS/10.0
    X-Powered-By                ASP.NET

    2) Subsequent requests to the CDN, no brotli compression:

    Access-Control-Allow-Origin *                                                                                           
    Age                         11                                                                                         
    Vary                        Accept-Encoding
    X-Cache                     HIT
    Content-Length              3529
    Cache-Control               max-age=604800
    Content-Type                application/javascript
    Date                        Tue, 14 Apr 2020 18:25:45 GMT
    Expires                     Tue, 21 Apr 2020 18:25:45 GMT
    ETag                        "1d60438744ea549+ident"
    Last-Modified               Fri, 27 Mar 2020 13:05:57 GMT
    Server                      ECAcc (ska/F77D)
    X-Powered-By                ASP.NET

    3) Requests to the Origin produces brotli-compressed responses

    Content-Encoding            br
    Vary                        Accept-Encoding
    Access-Control-Allow-Origin *
    Accept-Ranges               bytes
    Content-Length              1732
    Content-Type                application/javascript
    Date                        Tue, 14 Apr 2020 18:45:33 GMT
    ETag                        "1d60438744ea549"
    Last-Modified               Fri, 27 Mar 2020 13:05:57 GMT
    Set-Cookie                  <cookie-data>
    Server                      Microsoft-IIS/10.0
    X-Powered-By                ASP.NET

    Any ideas?

     


    Wednesday, April 15, 2020 10:43 AM
  • On Verizon end, on the fly compression mean compressing and caching an uncompressed asset and serving to the customer all in one request. Verizon don't support brotli compression on the fly. 

    We support brotli compression if the origin is compressing it using brotli compression. Basically the origin should have the uncompressed and br compressed version of the asset. If the asset is using a brotli compression in their request, the CDN will relay the request back to the origin and fetch the br compressed version of the asset and then serve it back to the customer. It won't be able to cache the compressed asset on the CDN though. 
    Wednesday, April 15, 2020 10:06 PM