Intent to Ship: Brotli (Accept-encoding: br on HTTPS connection)

[Kenji Baheux]

bcc: net...@chromium.org

Contact emails

Engineering: eus...@chromium.org, {jyrki, szabadka, lode}@google.com

PM: kenji...@chromium.org

Spec

IETF draft

Summary

Brotli is used in WOFF 2.0 web fonts with great success.

This intent to ship is about making Brotli available as a Content-Encoding method, advertised via Accept-Encoding: br. 

Important note: Brotli availability is restricted to HTTPS connections.

Advantages:

• Brotli outperforms gzip for typical web assets (e.g. css, html, js) by 17–25 %.

• Brotli -11 density compared to gzip -9:

• html (multi-language corpus): 25 % savings

• js (alexa top 10k): 17 % savings

• minified js (alexa top 10k): 17 % savings

• css (alexa top 10k): 20 % savings

More details in the white paper.

Link to “Intent to Implement” blink-dev discussion

Intent to implement thread

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

Brotli can be enabled in Chrome Canary via chrome://flags#enable-brotli

Here are a few live instances that we are aware of:

• Google Fonts API serves responses (CSS) compressed with Brotli to supporting browsers (observed a weighted average of 9% savings across the top 20 css requests with Brotli -6).

• CloudFlare serve their blog on an experimental HTTP2 server that also supports Brotli.

Debuggability

DevTools correctly shows the size (compressed, uncompressed) as well as the right value for the content-encoding header.

Interoperability and Compatibility Risk

Low risk:

• The Brotli spec has been independently reviewed and implemented by Mark Adler.

• Developer interest is high: interest from CDN vendors, tier1 web properties, third parties, nginx modules (cloudflare, google)...

• Brotli has been in use in WOFF2 web fonts for a while with no compatibility issues.

• Supporting Brotli for content-encoding is rather straightforward when you already support WOFF2

• WOFF2 is supported in Chrome, Opera, Firefox

• support for WOFF2 in Safari has recently landed (My read of webkit#150830)

• support for WOFF2 is under consideration for Edge.

• Brotli is supported by Firefox since M44 (also restricted to HTTPS connections)
  

• Brotli is under consideration by the Edge team (pending pull request by Kyle Pflug, Edge program manager)

• Brotli support in Safari: no public signals other than upcoming WOFF2 support (with Brotli under the hood)

OWP launch tracking bug

launch bug

Entry on the feature dashboard

https://www.chromestatus.com/feature/5420797577396224

Other: Brotli github repository

[bay...@gmail.com]

Looking at the Brotli implementation in Version 50.0.2626.0 canary (64-bit), I see that when I enable it via chrome://flags, "br" is added to the Accept-Encoding list as expected for HTTPS origins.

However, I was surprised to see that Chrome will accept and decode "br" responses even in the event that it did not include "br" in the Accept-Encoding (e.g. on a non-HTTPS origin). Here's a pair of test URLs:

https://www.bayden.com/test/brotliimg.aspx
http://www.bayden.com/test/brotliimg.aspx

This behavior is in contrast to Firefox 46 which will not decode Brotli if it didn't request it. It's also likely in contrast to eventual behavior of Microsoft Edge (which only decodes content encodings that it requested).

Is this expected?

[Chris Bentzel]

That seems like a bug, thanks for the report.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/bd0830fa-a93e-4c65-afce-4ff94394d154%40chromium.org.

[Chris Bentzel]

If you could file a bug at crbug.com that would be very helpful.

[bay...@gmail.com]

Done: https://code.google.com/p/chromium/issues/detail?id=579606

thanks!