Consent to the use of Personal Data and Cookies

This website needs your consent to use cookies in order to customize ads and content.

If you give us your consent, data may be shared with Google.

Brotli is not working over non-https

Why brotli is not supported over HTTP connections, and what you can do to get around the problem on local servers.


By. Jacob

Edited: 2021-11-29 16:53

By default, Brotli is not included in the accept-encoding header Google Chrome, Firefox and Safari, for http connections; apparently this is due to issues with web proxies that misbehave when they encounter non deflate/gzip Content-Encoding.

This is causing problems when developers need to test their brotli implementations on local servers, since those will often be running on HTTP rather than HTTPS.

There is a couple of nice solutions to this problem; one is to modify the accept-encoding header using a browser plugin, and another, my favorite, is to test implementations with cURL from a terminal:

curl -H "accept-encoding: br" --HEAD

So, the reason why your Browser does not include br in its accept-encoding over clean HTTP connections is, most likely, not because it does not support Brotli; you can still do your testing with tools such as cURL from a terminal.

Alternatively, you can also install a self-signed certificate on your local server. The problem with this is that the browser will complain that the connection is not secure.

Note. Beamtic's File Handler has support for Brotli, Deflate, and GZIP; when used to stream static files, it will automatically attempt to serve the best available and browser-supported compression.

Link: Class: File Handler

Tell us what you think: