Thank you for the clarification, Nidhi! Could you expand on the compatibility issues that might come up here? Given the overlap WebView has with Chrome in terms of source code, these might apply to both. Nevertheless, having WebView in the experiments from the start will help uncover WebView specific issues early and ensure a timely release (as opposed to Brotli support <https://chromestatus.com/feature/5420797577396224>) and a unified narrative, i.e. "*Zstd content-encoding support available for Android (Chrome and WebView)*".
On Tuesday, June 27, 2023 at 5:19:08 AM UTC+2 Nidhi Jaju wrote: > Thank you for reaching out, Mihai and Peter! > Our plan is to support this feature in WebView as well, but most likely a > few milestones after M117 so that we can deal with any compatibility issues > separately. I'll share further updates when we have more information on the > WebView rollout plan. > > Thanks, > Nidhi > > On Mon, Jun 26, 2023 at 7:27 PM Peter Beverloo <[email protected]> wrote: > >> Thank you for sharing the I2P Nidhi! What are your plans regarding >> supporting this feature in Android WebView? We're just rolling out support >> for Brotli there and we should aim for it to be on par with the browser >> regarding supported compression algorithms. >> >> Thanks, >> Peter >> >> >> On Thu, Jun 22, 2023 at 7:05 PM PhistucK <[email protected]> wrote: >> >>> If/when shipping, just remember to add this to the list of "Accepted >>> Content-Encodings" that shows up on the developer tools, under the "Network >>> conditions" panel. :) >>> [image: image.png] >>> >>> ☆*PhistucK* >>> >>> >>> On Wed, Jun 21, 2023 at 6:08 PM Dale Curtis <[email protected]> >>> wrote: >>> >>>> On Wed, Jun 21, 2023 at 3:18 AM Adam Rice <[email protected]> wrote: >>>> >>>>> Drive by question: Given that the codec is going to be in the browser, >>>>>> are there plans to surface this up to CompressionStreams? (same question >>>>>> applies for Brotli, I suppose) >>>>> >>>>> >>>>> For the zstd Content-Encoding, we will only be linking in the >>>>> decompression part of the zstd library. But for CompressionStreams, >>>>> supporting a format only for decompression and not for compression is >>>>> likely to confuse and frustrate developers. >>>>> >>>> >>>> FWIW, asymmetric codec capabilities are quite common in media and >>>> developers have adapted just fine. E.g., we may only have hevc/aac/theora >>>> decoding, but not encoding. >>>> >>>> >>>>> >>>>> So while I'd like to add Zstd to CompressionStreams, we'll need a good >>>>> justification for the extra binary size increase caused by linking in the >>>>> compression code. The same applies to Brotli. >>>>> >>>>> Thanks for the question! >>>>> >>>>> On Wed, 21 Jun 2023 at 18:53, Sangwhan Moon <[email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On 2023年06月21日 18時02分49秒 (+09:00), Nidhi Jaju wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Jun 21, 2023 at 3:35 PM Yoav Weiss <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Jun 21, 2023 at 8:15 AM Nidhi Jaju <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Contact [email protected] >>>>>>>> >>>>>>>> Explainer >>>>>>>> https://docs.google.com/document/d/1aDyUw4mAzRdLyZyXpVgWvO-eLpc4ERz7I_7VDIPo9Hc/edit?usp=sharing >>>>>>>> Specificationhttps://datatracker.ietf.org/doc/html/rfc8878 >>>>>>>> >>>>>>>> Design docs >>>>>>>> https://docs.google.com/document/d/14dbzMpsYPfkefAJos124uPrlkvW7jyPJhzjujSWws2k/edit?usp=sharing >>>>>>>> >>>>>>>> Summary >>>>>>>> >>>>>>>> Zstandard, or “zstd”, is a data compression mechanism described in >>>>>>>> RFC8878. It is a fast lossless compression algorithm, targeting >>>>>>>> real-time >>>>>>>> compression scenarios at zlib-level and better compression ratios. The >>>>>>>> "zstd" token was added as an IANA-registered Content-Encoding token as >>>>>>>> per >>>>>>>> https://datatracker.ietf.org/doc/html/rfc8878#name-content-encoding. >>>>>>>> Adding support for "zstd" as a Content-Encoding will help load pages >>>>>>>> faster >>>>>>>> and use less bandwidth. >>>>>>>> >>>>>>>> Blink componentInternals>Network >>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork> >>>>>>>> >>>>>>>> Motivation >>>>>>>> >>>>>>>> Supporting zstd content-encoding in the browser would allow sites >>>>>>>> to spend less time and CPU/power on compression on their servers, >>>>>>>> resulting >>>>>>>> in reduced server costs. There are several published benchmarks[i.e. >>>>>>>> 1 <https://facebook.github.io/zstd/#benchmarks>, 2 >>>>>>>> <https://peazip.github.io/fast-compression-benchmark-brotli-zstandard.html>] >>>>>>>> >>>>>>>> and existing research showing promising potential wins. Zstd is >>>>>>>> roughly >>>>>>>> three times faster than Brotli for decompression. Combined with zstd >>>>>>>> being >>>>>>>> faster at compression, this will result in faster page load times. >>>>>>>> Initial public proposalNone >>>>>>>> >>>>>>>> TAG reviewNone >>>>>>>> >>>>>>> >>>>>> Drive by question: Given that the codec is going to be in the >>>>>> browser, are there plans to surface this up to CompressionStreams? (same >>>>>> question applies for Brotli, I suppose) >>>>>> >>>>>> >>>>>>>> >>>>>>>> TAG review statusNot applicable >>>>>>>> >>>>>>>> Risks >>>>>>>> >>>>>>>> Interoperability and Compatibility >>>>>>>> >>>>>>>> Servers that have a broken implementation of zstd might exist, but >>>>>>>> the risk of this is small. Additionally, middleware and middleboxes >>>>>>>> like >>>>>>>> virus checkers that intercept HTTPS connections might not support >>>>>>>> zstd, but >>>>>>>> might fail to remove it from the Accept-Encoding header in the request. >>>>>>>> >>>>>>> >>>>>>> Are we planning to only support this encoding under secure contexts >>>>>>> and/or H2+ to reduce that risk? >>>>>>> >>>>>> >>>>>> Yes, we're only planning to support zstd encoding under secure >>>>>> contexts, same as Brotli. >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *Gecko*: No signal ( >>>>>>>> https://github.com/mozilla/standards-positions/issues/775) >>>>>>>> >>>>>>>> *WebKit*: No signal ( >>>>>>>> https://github.com/WebKit/standards-positions/issues/168) >>>>>>>> >>>>>>>> *Web developers*: Positive (https://crbug.com/1246971) Facebook >>>>>>>> (Yann) and Akamai (Nic) seem to be positive about zstd >>>>>>>> content-encoding >>>>>>>> support in the browser. Facebook is also excited to test the feature. >>>>>>>> >>>>>>>> *Other signals*: >>>>>>>> >>>>>>>> WebView application risks >>>>>>>> >>>>>>>> Does this intent deprecate or change behavior of existing APIs, >>>>>>>> such that it has potentially high risk for Android WebView-based >>>>>>>> applications? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Debuggability >>>>>>>> >>>>>>>> No special support needed. >>>>>>>> >>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>> ?Not yet. >>>>>>>> >>>>>>>> Flag nameZstdContentEncoding >>>>>>>> >>>>>>>> Requires code in //chrome?True >>>>>>>> >>>>>>>> Tracking bug >>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1246971 >>>>>>>> >>>>>>>> Estimated milestones >>>>>>>> Shipping on desktop 117 >>>>>>>> Shipping on Android 117 >>>>>>>> >>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>> https://chromestatus.com/feature/6186023867908096 >>>>>>>> >>>>>>>> Links to previous Intent discussions >>>>>>>> >>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>> <https://chromestatus.com/>. >>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "blink-dev" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to [email protected]. >>>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYANd_E77W1ki--h_XJM-%2B_fA3w1CriGgJmnbh1N3LwRDtw%40mail.gmail.com >>>>>>>> >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYANd_E77W1ki--h_XJM-%2B_fA3w1CriGgJmnbh1N3LwRDtw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>> >>>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "blink-dev" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYAN%3DdFzxxXGt%2BTscR9zfu-dF38u_E4rQ7ynv8C%3D1C67YPA%40mail.gmail.com >>>>>> >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYAN%3DdFzxxXGt%2BTscR9zfu-dF38u_E4rQ7ynv8C%3D1C67YPA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "blink-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC_ixdxjsRhddJWgPP%3DHF5dbU9L9feqi369310-kFAzM_R6GAw%40mail.gmail.com >>>>> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC_ixdxjsRhddJWgPP%3DHF5dbU9L9feqi369310-kFAzM_R6GAw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "blink-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPUDrwfV7F4QT_2g_CG9kypeujEKxaQ1MKe5fzVbY4uGSZifLw%40mail.gmail.com >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPUDrwfV7F4QT_2g_CG9kypeujEKxaQ1MKe5fzVbY4uGSZifLw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_JkoEUc77LGtAEMpt%2BQ%2BPeVJ028jbGzNrvM4y%2B09OBrYw%40mail.gmail.com >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_JkoEUc77LGtAEMpt%2BQ%2BPeVJ028jbGzNrvM4y%2B09OBrYw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >> >> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/118f6dad-17e3-4176-a391-04bb3bdfaab8n%40chromium.org.
