from:"Nidhi Jaju"

Re: [blink-dev] Intent to Ship: Zstd Content-Encoding

2024-02-14 Thread Nidhi Jaju

On Thu, Feb 15, 2024 at 12:50 AM David Benjamin 
wrote:

> On Wed, Feb 14, 2024 at 9:20 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>> LGTM1
>>
>> On Wednesday, February 14, 2024 at 2:36:10 AM UTC+1 Nidhi Jaju wrote:
>>
>> On Wed, Feb 14, 2024 at 2:48 AM James Hartig 
>> wrote:
>>
>> My employer ran into the window size during our pre-production validation
>> and it was difficult to debug since it was working in cURL, the zstd CLI,
>> and only presented itself on certain URLs. I appreciate Nidhi responding to
>> our issue so quickly and updating Chrome to have a more helpful error
>> message in the future. The Go package we use already updated their
>> default <https://github.com/klauspost/compress/pull/913> to 8MB (without
>> any awareness to Chrome's size) which should help future users of that
>> package but there might be other packages out there that might not have a
>> low enough default. The updated Chrome error message will help but only if
>> you run into that error message when testing; which might not if you happen
>> to be testing with small responses. I'm not sure where developers should be
>> looking to be aware of the window size. Does it make sense to mention in
>> the Chrome Status entry? If the spec is updated that might be good enough
>> but I just wanted to discuss other avenues that might be more
>> developer-aware.
>>
>>
>> Thank you, I've included these details about the window size limits under
>> the "Interoperability and Compatibility Risks" section in the ChromeStatus
>> entry.
>>
>> On Tue, Feb 13, 2024 at 6:43 PM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>
>>
>> On Tue, Feb 13, 2024 at 9:29 AM Nidhi Jaju 
>> wrote:
>>
>>
>>
>> On Tue, Feb 13, 2024 at 4:18 PM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>> Thanks for working on this!! This is extremely exciting!
>>
>> On Tue, Feb 13, 2024 at 1:11 AM Nidhi Jaju 
>> wrote:
>>
>> Contact emails
>>
>> nidhij...@chromium.org
>>
>> Explainer
>>
>> https://docs.google.com/document/d/1aDyUw4mAzRdLyZyXpVgWvO-
>> eLpc4ERz7I_7VDIPo9Hc/edit?usp=sharing
>>
>> Specification
>>
>> https://datatracker.ietf.org/doc/html/rfc8878
>>
>> Design docs
>>
>> https://docs.google.com/document/d/14dbzMpsYPfkefAJos124uPrlkvW7j
>> yPJhzjujSWws2k/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, and spend less time and CPU/power on
>> compression on our servers, resulting in reduced server costs.
>>
>> Blink component
>>
>> Internals>Network
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork>
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/930
>>
>> TAG review status
>>
>> Pending
>>
>> 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.
>>
>> Another known risk is interoperability between clients that support zstd
>> regarding window frame sizes. In Chrome, we limit the window frame size to
>> 8MB to prevent excessive memory usage, but this limit does not exist in
>> curl and when using zstd directly. We have seen very few sites that use a
>> window size larger than 8MB which causes decoding errors, but we have added
>> new net error codes and debugging messages to help them understand what to
>> do in this situation.
>>
>>
>> I know we discussed
>> <https://w3c.github.io/web-performance/meetings/2023/2023-09-TPAC/index.html#h.xn2d3li0b8op>
>> this at length at the WebPerfWG.
>> Can you summarize developments and/or findings since that discussion on
>> that front?
>

Re: [blink-dev] Intent to Ship: Zstd Content-Encoding

2024-02-13 Thread Nidhi Jaju

On Wed, Feb 14, 2024 at 2:48 AM James Hartig  wrote:

> My employer ran into the window size during our pre-production validation
> and it was difficult to debug since it was working in cURL, the zstd CLI,
> and only presented itself on certain URLs. I appreciate Nidhi responding to
> our issue so quickly and updating Chrome to have a more helpful error
> message in the future. The Go package we use already updated their default
> <https://github.com/klauspost/compress/pull/913> to 8MB (without any
> awareness to Chrome's size) which should help future users of that package
> but there might be other packages out there that might not have a low
> enough default. The updated Chrome error message will help but only if you
> run into that error message when testing; which might not if you happen to
> be testing with small responses. I'm not sure where developers should be
> looking to be aware of the window size. Does it make sense to mention in
> the Chrome Status entry? If the spec is updated that might be good enough
> but I just wanted to discuss other avenues that might be more
> developer-aware.


Thank you, I've included these details about the window size limits under
the "Interoperability and Compatibility Risks" section in the ChromeStatus
entry.

On Tue, Feb 13, 2024 at 6:43 PM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

>
>
> On Tue, Feb 13, 2024 at 9:29 AM Nidhi Jaju  wrote:
>
>>
>>
>> On Tue, Feb 13, 2024 at 4:18 PM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>> Thanks for working on this!! This is extremely exciting!
>>>
>>> On Tue, Feb 13, 2024 at 1:11 AM Nidhi Jaju 
>>> wrote:
>>>
>>>> Contact emails
>>>>
>>>> nidhij...@chromium.org
>>>>
>>>> Explainer
>>>>
>>>>
>>>> https://docs.google.com/document/d/1aDyUw4mAzRdLyZyXpVgWvO-eLpc4ERz7I_7VDIPo9Hc/edit?usp=sharing
>>>>
>>>> Specification
>>>>
>>>> https://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, and spend less time and CPU/power on
>>>> compression on our servers, resulting in reduced server costs.
>>>>
>>>> Blink component
>>>>
>>>> Internals>Network
>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork>
>>>>
>>>> TAG review
>>>>
>>>> https://github.com/w3ctag/design-reviews/issues/930
>>>>
>>>> TAG review status
>>>>
>>>> Pending
>>>>
>>>> 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.
>>>>
>>>> Another known risk is interoperability between clients that support
>>>> zstd regarding window frame sizes. In Chrome, we limit the window frame
>>>> size to 8MB to prevent excessive memory usage, but this limit does not
>>>> exist in curl and when using zstd directly. We have seen very few sites
>>>> that use a window size larger than 8MB which causes decoding errors, but we
>>>> have added new net error codes and debugging messages to help them
>>>> understand what to do in this situation.
>>>>
>>>
>>> I know we discussed
>>> <https://w3c.github.io/web-performance/meetings/2023/2023-09-TPAC/index.html#h.xn2d3li0b8op>
>>> this at length at the WebPerfWG.
>>> Can you summarize developments and/or findings since that

Re: [blink-dev] Intent to Ship: Zstd Content-Encoding

2024-02-13 Thread Nidhi Jaju

On Tue, Feb 13, 2024 at 4:18 PM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

> Thanks for working on this!! This is extremely exciting!
>
> On Tue, Feb 13, 2024 at 1:11 AM Nidhi Jaju  wrote:
>
>> Contact emails
>>
>> nidhij...@chromium.org
>>
>> Explainer
>>
>>
>> https://docs.google.com/document/d/1aDyUw4mAzRdLyZyXpVgWvO-eLpc4ERz7I_7VDIPo9Hc/edit?usp=sharing
>>
>> Specification
>>
>> https://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, and spend less time and CPU/power on
>> compression on our servers, resulting in reduced server costs.
>>
>> Blink component
>>
>> Internals>Network
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork>
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/930
>>
>> TAG review status
>>
>> Pending
>>
>> 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.
>>
>> Another known risk is interoperability between clients that support zstd
>> regarding window frame sizes. In Chrome, we limit the window frame size to
>> 8MB to prevent excessive memory usage, but this limit does not exist in
>> curl and when using zstd directly. We have seen very few sites that use a
>> window size larger than 8MB which causes decoding errors, but we have added
>> new net error codes and debugging messages to help them understand what to
>> do in this situation.
>>
>
> I know we discussed
> <https://w3c.github.io/web-performance/meetings/2023/2023-09-TPAC/index.html#h.xn2d3li0b8op>
> this at length at the WebPerfWG.
> Can you summarize developments and/or findings since that discussion on
> that front?
> Should we expect the default output of CLI tools to be compatible with
> what we want to ship here?
> Should we expect interoperability between Chromium and e.g. curl?
>

We've been discussing it with the zstd team at Meta at
https://github.com/facebook/zstd/issues/2713. The plan is to take it to the
HTTP WG at the IETF and either file an errata or publish a new document
with more strict window size guidelines. The zstd CLI tool currently
supports up to 8MB as a default, so the same limit. The library will use
128MB by default, however, and Curl currently supports up to 128MB windows.
We expect those defaults to change to match any spec changes. In practice,
we've seen very limited reports of sites running into this limit, and we've
added helpful messages in Chromium to guide anyone who does run into it.


>
>
>> Gecko: Positive (
>> https://github.com/mozilla/standards-positions/issues/775)
>>
>> WebKit: Positive (
>> https://github.com/WebKit/standards-positions/issues/168)
>>
>> Web developers: Positive (https://crbug.com/1246971) Meta (Yann and
>> Felix) and Akamai (Nic) are positive about zstd content-encoding on the
>> browser. Meta has collaborated with us to improve the compression ratios
>> for Meta origins during the experiment and is seeing positive user-level
>> results. Alibaba is also supportive of shipping zstd support as they saw
>> massive savings on their origins in terms of server CPU cost.
>>
>> Other signals:
>>
>> Ergonomics
>>
>> While both Zstandard and Brotli are clear wins over gzip
>> content-encoding, which of Zstandard or Brotli to use depends on many
>> factors, and site authors may need to experiment to identify the optimal
>> choice for their content.
>>
>> Zstandard uses more memory for decompression than gzip. However, this is
>> also true for Brotli, and we haven't seen any problems in practice.
>>
>> Activation
>>
&

[blink-dev] Intent to Ship: Zstd Content-Encoding

2024-02-12 Thread Nidhi Jaju

Contact emails

nidhij...@chromium.org

Explainer

https://docs.google.com/document/d/1aDyUw4mAzRdLyZyXpVgWvO-eLpc4ERz7I_7VDIPo9Hc/edit?usp=sharing

Specification

https://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, and spend less time and CPU/power on compression on
our servers, resulting in reduced server costs.

Blink component

Internals>Network

TAG review

https://github.com/w3ctag/design-reviews/issues/930

TAG review status

Pending

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.

Another known risk is interoperability between clients that support zstd
regarding window frame sizes. In Chrome, we limit the window frame size to
8MB to prevent excessive memory usage, but this limit does not exist in
curl and when using zstd directly. We have seen very few sites that use a
window size larger than 8MB which causes decoding errors, but we have added
new net error codes and debugging messages to help them understand what to
do in this situation.

Gecko: Positive (https://github.com/mozilla/standards-positions/issues/775)

WebKit: Positive (https://github.com/WebKit/standards-positions/issues/168)

Web developers: Positive (https://crbug.com/1246971) Meta (Yann and Felix)
and Akamai (Nic) are positive about zstd content-encoding on the browser.
Meta has collaborated with us to improve the compression ratios for Meta
origins during the experiment and is seeing positive user-level results.
Alibaba is also supportive of shipping zstd support as they saw massive
savings on their origins in terms of server CPU cost.

Other signals:

Ergonomics

While both Zstandard and Brotli are clear wins over gzip content-encoding,
which of Zstandard or Brotli to use depends on many factors, and site
authors may need to experiment to identify the optimal choice for their
content.

Zstandard uses more memory for decompression than gzip. However, this is
also true for Brotli, and we haven't seen any problems in practice.

Activation

The "zstd" Content-Encoding is not as widely supported by HTTP servers as
gzip. Of the top 5 web servers, Nginx has a third-party module, which
should also work for OpenResty (untested). Apache, IIS, and LiteSpeed
appear to have no support. Explicit server support is often only necessary
for dynamic content. For static (pre-compressed) content, Zstandard can
often be supported just by configuration.

Only one public CDN is known to be able to compress Zstandard itself, and
some CDN's may require custom configuration to pass-through Zstandard
correctly.

Zstd support is not particularly difficult to implement for a server that
already implements multiple content encodings. The C implementation has a
straightforward API and there are implementations for many other languages.
There is also a lively community of Zstandard enthusiasts which should help
accelerate adoption.

Security

CRIME and BREACH
mean that the resource being
compressed can be considered readable by the document deploying them. That
is bad if any of them contains information that the document cannot already
obtain by other means. An attacker may provide correctly formed compressed
frames with unreasonable memory requirements, and dictionaries may interact
unexpectedly with a decoder, leading to possible memory or other
resource-exhaustion attacks. It is possible to store arbitrary user
metadata in skippable frames, so they can be used as a watermark to track
the path of the compressed payload. It is important to note that these
concerns apply to all compression formats, not just zstd.

To mitigate these risks, similar to Brotli, we'll be advertising support
for "zstd" encoding only if transferred data is opaque to proxies, to
ensure that resources don't contain private data that the origin cannot
read otherwise.

Adding zstd to third_party/ in Chromium adds a large new code surface that
processes untrusted data, which inevitably brings risks of new security
holes. However, this is mitigated by the extensive fuzzing and security
analysis

Re: [blink-dev] Intent to Experiment: Zstd Content-Encoding

2023-10-11 Thread Nidhi Jaju

Hi Lee,

I'm glad you were able to patch the error ahead of a more general rollout!

Regarding your second point, there's two ways you can explicitly turn on
the feature:
1. If there's a "Flag name on chrome://flags" in the Intent to Experiment,
you can manually turn on the feature by navigating to chrome://flags. So in
this case, you could force your browser to turn on
chrome://flags/#enable-zstd-content-encoding.
2. If there's a "Finch feature name", you can pass
`--enable-features=FeatureName` (i.e.
`--enable-features=ZstdContentEncoding` in this case) when running Chrome
from the command line.

You can also keep an eye out for ongoing experiments and planned features
at https://chromestatus.com/roadmap.

Hopefully that helps.

Regards,
Nidhi

On Thu, Oct 12, 2023 at 2:51 AM Lee Benson  wrote:

> This actually triggered a small internal incident at Datadog on a private
> API that wasn't set-up to handle Zstandard encoding properly.
>
> So two things:
>
> 1. Firstly, thanks for bringing this this our attention! We were able to
> patch the error ahead of a more general roll-out to public users.
> 2. Is there a way we can explicitly opt in to these kinds of A/B tests to
> preemptively catch more of these breaking changes?
>
> This would be particularly useful to our synthetics.
>
> Thanks,
> Lee
>
> On Saturday, 15 July 2023 at 07:33:52 UTC-4 Nidhi Jaju wrote:
>
>> Hi Mike,
>>
>> The proposed experiment is to run an A/B experiment on Canary/Dev, Beta,
>> and then 1% of Stable on M117.
>>
>> Best,
>> Nidhi
>>
>> On Sat, Jul 15, 2023 at 12:32 AM Mike Taylor 
>> wrote:
>>
>>> Can you clarify the proposed experiment (presumably N% of stable?) and
>>> the desired milestones? Thanks!
>>> On 7/14/23 4:57 AM, Nidhi Jaju wrote:
>>>
>>> Contact emails nidh...@chromium.org
>>>
>>> Explainer
>>> https://docs.google.com/document/d/1aDyUw4mAzRdLyZyXpVgWvO-eLpc4ERz7I_7VDIPo9Hc/edit?usp=sharing
>>>
>>> Specification https://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 component Internals>Network
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork>
>>>
>>> TAG review None
>>>
>>> TAG review status Not 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.
>>>
>>> *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 in the
>>> browser. Facebook is also excited to test the feature.
>>>
>>> *Other signals*:
>>>
>>> Security
>>>
>>> CRIME and BREACH mean that the resource being compressed can be
>>> considered readable by the document deploying them. That is bad if any of
>>> them contains information that the document cannot already obtain by other
>>> means. An attacker may provide correctly formed compressed frames with
>>> unreasonable memory requirements, and dictionaries may interact
>>> unexpectedly with a decoder, leading to possible memory or other
>>> resource-exhaustion attacks. It is possible to store arbitrary user
>>> metadata in skippable frames, so they can be used as a watermark to track
>>> the path of the compressed payload. It is important to note

Re: [blink-dev] Intent to Experiment: Zstd Content-Encoding

2023-07-15 Thread Nidhi Jaju

Hi Mike,

The proposed experiment is to run an A/B experiment on Canary/Dev, Beta,
and then 1% of Stable on M117.

Best,
Nidhi

On Sat, Jul 15, 2023 at 12:32 AM Mike Taylor  wrote:

> Can you clarify the proposed experiment (presumably N% of stable?) and the
> desired milestones? Thanks!
> On 7/14/23 4:57 AM, Nidhi Jaju wrote:
>
> Contact emails nidhij...@chromium.org
>
> Explainer
> https://docs.google.com/document/d/1aDyUw4mAzRdLyZyXpVgWvO-eLpc4ERz7I_7VDIPo9Hc/edit?usp=sharing
>
> Specification https://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 component Internals>Network
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork>
>
> TAG review None
>
> TAG review status Not 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.
>
> *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 in the
> browser. Facebook is also excited to test the feature.
>
> *Other signals*:
>
> Security
>
> CRIME and BREACH mean that the resource being compressed can be considered
> readable by the document deploying them. That is bad if any of them
> contains information that the document cannot already obtain by other
> means. An attacker may provide correctly formed compressed frames with
> unreasonable memory requirements, and dictionaries may interact
> unexpectedly with a decoder, leading to possible memory or other
> resource-exhaustion attacks. It is possible to store arbitrary user
> metadata in skippable frames, so they can be used as a watermark to track
> the path of the compressed payload. It is important to note that these
> concerns apply to all compression formats, not just zstd.
>
> To mitigate these risks, similar to Brotli, we'll be advertising support
> for "zstd" encoding only if transferred data is opaque to proxy, to ensure
> that resources don't contain private data that the origin cannot read
> otherwise.
>
> Adding zstd to Chromium adds a large new code surface that processes
> untrusted data, which inevitably brings risks of new security holes.
> However, this is mitigated by the extensive fuzzing and security analysis
> done on zstd by Google and other community members.
>
> 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?
>
>
> Goals for experimentation Understand the impact of supporting zstd
> content-encoding in the browser on performance and if there's breakage.
>
> Ongoing technical constraints
>
> Debuggability
>
> No special support needed. Zstd content-encoding support will be exposed
> to the devtools protocol, so developers are able to override it and view
> the headers from the inspector.
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)? Yes
>
> Is this feature fully tested by web-platform-tests
> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
> ? No
>
> Flag name on chrome://flags enable-zstd-content-encoding
>
> Finch feature name ZstdContentEncoding
>
> Requires code in //chrome? True
>
> Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1246971
>
> Launch bug https://launch.corp.google.com/launch/4266275
>
> Estimated milestones
> Shipping on desktop 117
> Shipping on Android 117
> Shipping on WebView 117
>
> Link to entry on the Chrome Platform Status
> https

[blink-dev] Intent to Experiment: Zstd Content-Encoding

2023-07-14 Thread Nidhi Jaju

Contact emailsnidhij...@chromium.org

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

Blink componentInternals>Network

TAG reviewNone

TAG review statusNot applicable

Risks

Interoperability and Compatibility

*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 in the
browser. Facebook is also excited to test the feature.

*Other signals*:

Security

CRIME and BREACH mean that the resource being compressed can be considered
readable by the document deploying them. That is bad if any of them
contains information that the document cannot already obtain by other
means. An attacker may provide correctly formed compressed frames with
unreasonable memory requirements, and dictionaries may interact
unexpectedly with a decoder, leading to possible memory or other
resource-exhaustion attacks. It is possible to store arbitrary user
metadata in skippable frames, so they can be used as a watermark to track
the path of the compressed payload. It is important to note that these
concerns apply to all compression formats, not just zstd.

To mitigate these risks, similar to Brotli, we'll be advertising support
for "zstd" encoding only if transferred data is opaque to proxy, to ensure
that resources don't contain private data that the origin cannot read
otherwise.

Adding zstd to Chromium adds a large new code surface that processes
untrusted data, which inevitably brings risks of new security holes.
However, this is mitigated by the extensive fuzzing and security analysis
done on zstd by Google and other community members.

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?

Goals for experimentation

Understand the impact of supporting zstd content-encoding in the browser on
performance and if there's breakage.

Ongoing technical constraints

Debuggability

No special support needed. Zstd content-encoding support will be exposed to
the devtools protocol, so developers are able to override it and view the
headers from the inspector.

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

Is this feature fully tested by web-platform-tests

?No

Flag name on chrome://flagsenable-zstd-content-encoding

Finch feature nameZstdContentEncoding

Requires code in //chrome?True

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1246971

Launch bughttps://launch.corp.google.com/launch/4266275

Estimated milestones
Shipping on desktop 117
Shipping on Android 117
Shipping on WebView 117

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/6186023867908096

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYANd_E77W1ki--h_XJM-%2B_fA3w1CriGgJmnbh1N3LwRDtw%40mail.gmail.com

This intent message was generated by Chrome Platform Status
.

--
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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYANR%3DisgShRGxHQMgn-2W1%2BteA81AtyRu14v7s_kk2C90Q%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype: Zstd Content-Encoding

2023-06-26 Thread Nidhi Jaju

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  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  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 
>> wrote:
>>
>>> On Wed, Jun 21, 2023 at 3:18 AM Adam Rice  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  wrote:
>>>>
>>>>>
>>>>>
>>>>> On 2023年06月21日 18時02分49秒 (+09:00), Nidhi Jaju wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Jun 21, 2023 at 3:35 PM Yoav Weiss 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jun 21, 2023 at 8:15 AM Nidhi Jaju 
>>>>>> wrote:
>>>>>>
>>>>>>> Contact emailsnidhij...@chromium.org
>>>>>>>
>>>>>>> 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
>>>>>>>

Re: [blink-dev] Intent to Prototype: Zstd Content-Encoding

2023-06-21 Thread Nidhi Jaju

On Wed, Jun 21, 2023 at 3:35 PM Yoav Weiss  wrote:

>
>
> On Wed, Jun 21, 2023 at 8:15 AM Nidhi Jaju  wrote:
>
>> Contact emailsnidhij...@chromium.org
>>
>> 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
>>
>> 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 bughttps://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 blink-dev+unsubscr...@chromium.org.
>> 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_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 blink-dev+unsubscr...@chromium.org.
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.

[blink-dev] Intent to Prototype: Zstd Content-Encoding

2023-06-21 Thread Nidhi Jaju

Contact emailsnidhij...@chromium.org

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

Blink componentInternals>Network

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
, 2
]
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

TAG review statusNot applicable

Risks

Interoperability and Compatibility

*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

?Not yet.

Flag nameZstdContentEncoding

Requires code in //chrome?True

Tracking bughttps://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
.

--
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 blink-dev+unsubscr...@chromium.org.
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.

Re: [blink-dev] Intent to Ship: BYOB support for Fetch

2023-06-06 Thread Nidhi Jaju

On Tue, Jun 6, 2023 at 1:01 PM Yoav Weiss  wrote:

>
>
> On Monday, June 5, 2023 at 1:13:11 PM UTC+2 Nidhi Jaju wrote:
>
> Thank you, Mike and Yoav!
>
> I filed a standards position request with WebKit, and they are supportive
> as well: https://github.com/WebKit/standards-positions/issues/194.
>
>
> That's great!!
>
>
>
> On Wed, May 31, 2023 at 9:33 PM Yoav Weiss  wrote:
>
> Thanks for aligning with Firefox here!
>
> On Fri, May 26, 2023 at 5:32 AM Nidhi Jaju  wrote:
>
> Contact emailsnidhij...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://fetch.spec.whatwg.org/#http-network-fetch
>
> Summary
>
> Makes Response.body be a readable byte stream instead of a "default"
> readable stream. This enables it to be used with bring-your-own-buffer
> (BYOB) readers, reducing garbage collection overhead and copies.
>
> As mentioned in the Activation section below, we plan to ship the
> ReadableStreamTeeCloneForBranch2 feature first, and then the FetchBYOB
> feature later.
> Blink componentBlink>Network>FetchAPI
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ENetwork%3EFetchAPI>
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> Low risk because streams and fetch have already been standardized for a
> long time. Other browsers have implemented other parts of the standard, and
> Firefox has already shipped this behavior for many months and others will
> most likely also adapt this feature as well soon.
>
>
> *Gecko*: Shipped/Shipping (https://github.com/whatwg/
> fetch/issues/267#issuecomment-1350303670) Already shipped in Firefox in
> 2022.
>
> *WebKit*: Positive (https://github.com/whatwg/fetch/pull/1593) @annevk
> from Apple approved the PR to update the spec with relevant changes and
> expressed interest as an implementer on behalf of Apple.
>
> *Web developers*: No signals
>
> *Other signals*: Deno is also interested in, and somewhat shipped, this
> behavior (https://github.com/denoland/deno/issues/17386).
>
> Activation
>
> Currently, to clone a body, we tee the body's stream, but teeing always
> returns two "default" streams, where the chunks are not cloned for both
> streams. Making Response.body into a byte stream, will mean that cloning it
> will result in cloning the chunks for the second stream, which is different
> behavior. In order to mitigate activation risks, we are splitting this
> change into two releases. One where the default teeing behavior will also
> start to clone for the second stream behind the "
> ReadableStreamTeeCloneForBranch2" feature flag, and then make
> Response.body a readable byte stream behind the "FetchBYOB" feature flag.
>
>
> Can you help me understand what potential breakage (if any) may look like?
> How would these 2 behavior changes break developer expectations? What
> would code that breaks as a result of this look like?
>
> The 2 changes are incremental, and will only break developer expectations
> if there are websites that rely on the output of cloning a request/response
> to have the same chunks as before or rely on modifying one of the chunks
> changing the other one.
>
> A code sample of where the behavior difference would be observable is:
> const request = new Request("image.jpg");
> fetch(request).then((response) => {
>   const cloned_response = response.clone();
>
>   const { value: value1 } = await response.getReader().read();
>   const { value: value2 } = await cloned_response.getReader().read();
>
>   if (value1 === value2) {
> console.log('old behavior');
>   } else {
> console.log('new behavior');
>   }
> });
>
> In both the old and the new behaviour, the contents of the Uint8Array are
> the same, so it only makes a practical difference if a script modifies the
> output.
>
>
> Do we have a sense of an upper bound on potential breakage? e.g. a use
> counter for fetch response cloning?
>

There's no use counter for fetch response cloning, but we believe the
breakage will be extremely low, and may not even be a concern. There's not
too many realistic scenarios where we might observe a breakage i.e. if the
stream is input to some other API, for example the Cache API, then the site
can't control the timing when the chunk will be consumed. If a service
worker tries modifying a chunk after it has been queued, it is not
guaranteed whether it will have been read by the Cache API yet or not, and
so whether the modification makes it into the cache will not be
deterministic. Hence, it's unlikely a site could be relying on that
behaviour.


>
>
> (An explainer that outlined

Re: [blink-dev] Intent to Ship: BYOB support for Fetch

2023-06-05 Thread Nidhi Jaju

Thank you, Mike and Yoav!

I filed a standards position request with WebKit, and they are supportive
as well: https://github.com/WebKit/standards-positions/issues/194.

On Wed, May 31, 2023 at 9:33 PM Yoav Weiss  wrote:

> Thanks for aligning with Firefox here!
>
> On Fri, May 26, 2023 at 5:32 AM Nidhi Jaju  wrote:
>
>> Contact emailsnidhij...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://fetch.spec.whatwg.org/#http-network-fetch
>>
>> Summary
>>
>> Makes Response.body be a readable byte stream instead of a "default"
>> readable stream. This enables it to be used with bring-your-own-buffer
>> (BYOB) readers, reducing garbage collection overhead and copies.
>>
>> As mentioned in the Activation section below, we plan to ship the
>> ReadableStreamTeeCloneForBranch2 feature first, and then the FetchBYOB
>> feature later.
>> Blink componentBlink>Network>FetchAPI
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ENetwork%3EFetchAPI>
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Low risk because streams and fetch have already been standardized for a
>> long time. Other browsers have implemented other parts of the standard, and
>> Firefox has already shipped this behavior for many months and others will
>> most likely also adapt this feature as well soon.
>>
>>
>> *Gecko*: Shipped/Shipping (
>> https://github.com/whatwg/fetch/issues/267#issuecomment-1350303670)
>> Already shipped in Firefox in 2022.
>>
>> *WebKit*: Positive (https://github.com/whatwg/fetch/pull/1593) @annevk
>> from Apple approved the PR to update the spec with relevant changes and
>> expressed interest as an implementer on behalf of Apple.
>>
>> *Web developers*: No signals
>>
>> *Other signals*: Deno is also interested in, and somewhat shipped, this
>> behavior (https://github.com/denoland/deno/issues/17386).
>>
>> Activation
>>
>> Currently, to clone a body, we tee the body's stream, but teeing always
>> returns two "default" streams, where the chunks are not cloned for both
>> streams. Making Response.body into a byte stream, will mean that cloning it
>> will result in cloning the chunks for the second stream, which is different
>> behavior. In order to mitigate activation risks, we are splitting this
>> change into two releases. One where the default teeing behavior will also
>> start to clone for the second stream behind the
>> "ReadableStreamTeeCloneForBranch2" feature flag, and then make
>> Response.body a readable byte stream behind the "FetchBYOB" feature flag.
>>
>
> Can you help me understand what potential breakage (if any) may look like?
> How would these 2 behavior changes break developer expectations? What
> would code that breaks as a result of this look like?
>
The 2 changes are incremental, and will only break developer expectations
if there are websites that rely on the output of cloning a request/response
to have the same chunks as before or rely on modifying one of the chunks
changing the other one.

A code sample of where the behavior difference would be observable is:
const request = new Request("image.jpg");
fetch(request).then((response) => {
  const cloned_response = response.clone();

  const { value: value1 } = await response.getReader().read();
  const { value: value2 } = await cloned_response.getReader().read();

  if (value1 === value2) {
console.log('old behavior');
  } else {
console.log('new behavior');
  }
});

In both the old and the new behaviour, the contents of the Uint8Array are
the same, so it only makes a practical difference if a script modifies the
output.

(An explainer that outlined that would've been helpful, but inline
> explanations are fine as well)
>

>
>>
>>
>> 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.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>
>> This feature will be purely implemented in Blink and so cross-platform
>> support is automatic.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ?Y

[blink-dev] Intent to Ship: BYOB support for Fetch

2023-05-26 Thread Nidhi Jaju

Contact emailsnidhij...@chromium.org

ExplainerNone

Specificationhttps://fetch.spec.whatwg.org/#http-network-fetch

Summary

Makes Response.body be a readable byte stream instead of a "default"
readable stream. This enables it to be used with bring-your-own-buffer
(BYOB) readers, reducing garbage collection overhead and copies.

As mentioned in the Activation section below, we plan to ship the
ReadableStreamTeeCloneForBranch2 feature first, and then the FetchBYOB
feature later.
Blink componentBlink>Network>FetchAPI

TAG reviewNone

TAG review statusNot applicable

Risks

Interoperability and Compatibility

Low risk because streams and fetch have already been standardized for a
long time. Other browsers have implemented other parts of the standard, and
Firefox has already shipped this behavior for many months and others will
most likely also adapt this feature as well soon.

*Gecko*: Shipped/Shipping (
https://github.com/whatwg/fetch/issues/267#issuecomment-1350303670) Already
shipped in Firefox in 2022.

*WebKit*: Positive (https://github.com/whatwg/fetch/pull/1593) @annevk from
Apple approved the PR to update the spec with relevant changes and
expressed interest as an implementer on behalf of Apple.

*Web developers*: No signals

*Other signals*: Deno is also interested in, and somewhat shipped, this
behavior (https://github.com/denoland/deno/issues/17386).

Activation

Currently, to clone a body, we tee the body's stream, but teeing always
returns two "default" streams, where the chunks are not cloned for both
streams. Making Response.body into a byte stream, will mean that cloning it
will result in cloning the chunks for the second stream, which is different
behavior. In order to mitigate activation risks, we are splitting this
change into two releases. One where the default teeing behavior will also
start to clone for the second stream behind the
"ReadableStreamTeeCloneForBranch2" feature flag, and then make
Response.body a readable byte stream behind the "FetchBYOB" feature flag.

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.

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

This feature will be purely implemented in Blink and so cross-platform
support is automatic.

Is this feature fully tested by web-platform-tests

?Yes

Flag nameReadableStreamTeeCloneForBranch2 and FetchBYOB

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1243329

Estimated milestones
Shipping on desktop 116
Shipping on Android 116
Shipping on WebView 116

Anticipated spec changes

Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github issues
in the project for the feature specification) whose resolution may
introduce web compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).
None. The spec change for BYOB support for Fetch was already landed at
https://github.com/whatwg/fetch/pull/1593.

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5192003450568704

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/Iyt6Ca9PiJQ/m/s_D7A0YwCgAJ

--
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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYANt%2BwCoAYOfh1Bj7EJrdTz3jkd%3D%3DAyeBv9f8P2Ccu1wkg%40mail.gmail.com.

[blink-dev] Intent to Prototype: BYOB support for Fetch

2023-04-17 Thread Nidhi Jaju

Contact emailsnidhij...@chromium.org

ExplainerNone

Specificationhttps://fetch.spec.whatwg.org/#http-network-fetch

Summary

Blink componentBlink>Network>FetchAPI

Motivation

Using readable byte streams for Response.body allows more precise memory
allocation, minimizes buffer copies, and reduces GC overhead.

Initial public proposalNone

TAG reviewNone

TAG review statusNot applicable

Risks

Interoperability and Compatibility

*Gecko*: Shipped/Shipping (
https://github.com/whatwg/fetch/issues/267#issuecomment-1350303670) Already
shipped in Firefox in 2022.

*WebKit*: Positive (https://github.com/whatwg/fetch/pull/1593) @annevk from
Apple approved the PR to update the spec with relevant changes and
expressed interest as an implementer on behalf of Apple.

*Web developers*: No signals

*Other signals*: Deno is also interested in, and somewhat shipped, this
behavior (https://github.com/denoland/deno/issues/17386).

Activation

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

?Yes
https://wpt.fyi/results/fetch/api/response/response-consume-stream.any.html?label=experimental=master

Flag nameReadableStreamTeeCloneForBranch2 and FetchBYOB

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1243329

Estimated milestones
Shipping on desktop 115
Shipping on Android 115
Shipping on WebView 115

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5192003450568704

--
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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYAPyZ-TJsC5%3DtgYp_hBbrQtaspep2HRmDyLX7tJQFNGp%3Dw%40mail.gmail.com.

[blink-dev] PSA: Support for teeing readable byte streams

2023-04-12 Thread Nidhi Jaju

Hi all,

(If you do not work with readable byte streams, you can ignore this.)

We have recently landed the implementation
<https://chromium-review.googlesource.com/c/chromium/src/+/3757034> of
teeing support for readable byte streams in Blink based on the corresponding
spec changes <https://github.com/whatwg/streams/pull/1114> to the Streams
API standard. This improves standards compliance.

Based on these changes, teeing a byte stream will now result in creating
two readable byte streams, instead of two default readable streams. The
implementation also now clones the chunks, instead of using the same
ArrayBufferView, when teeing. This means that if you compare the output of
the two streams, it’s possible to observe that the objects differ with the
new behavior, which is demonstrated by the following script:

const byteStream = new ReadableStream({ type: ‘bytes’ });

const [branch1, branch2] = byteStream.tee();

const { value: value1 } = branch1.getReader().read();

const { value: value2 } = branch2.getReader().read();

if (value1 === value2) {

  console.log('old behavior');

} else {

  console.log('new behavior');

}

Cheers,
Nidhi Jaju

-- 
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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYAM0D65zT6Q3Cpg0N%3Dk58L5t96JRRES%2BpBCOvXseL4SOBQ%40mail.gmail.com.

[blink-dev] PSA: Adding 'Set-Cookie' header to Fetch's forbidden header names

2022-06-21 Thread Nidhi Jaju

tl;dr: Chrome will start blocking 'Set-Cookie' request headers on outbound
fetch requests.

Long version:

The getAll() interface for Headers requires special complex handling of the
Set-Cookie header, as it cannot just be combined, since it is semantically
a response header. By forbidding 'Set-Cookie' as a request header, we avoid
leaking this complexity into requests, as it is not useful for requests
anyway. (spec discussion )

There was a UseCounter (results
) that
was added to verify the usage of 'Set-Cookie' header on outbound fetch
requests in Chromium. It was concluded that the % of pages that set a
"set-cookie" header on an outbound fetch request hovers around 0.0003%.
Further testing indicated that the two most popular domains that set the
'Set-Cookie' header on outbound fetch requests, still continue to work fine
when all outbound 'Set-Cookie' headers were removed (i.e. return 200 status
codes, identical data, identical response headers). As such, it was
concluded that we could safely make this change.

This is technically a web-facing change, though a small change to bring the
Chrome implementation in line with the Fetch spec (spec PR
). The impact seems small (as
indicated by the UseCounter), and only positive by reducing complexity.

Regards,

Nidhi

--
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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYAMybV%3DZgJ00UufGZEDb_m5KGoCJ26uk_dJPYOKmQD4GDg%40mail.gmail.com.

Re: [blink-dev] Intent to Experiment: Load common payloads from privacy-preserving single-keyed cache

2022-04-26 Thread Nidhi Jaju

Hi Noam,

Apologies for the confusion! The list of the top 100 pervasive payloads for
use in the experiment is pending internal reviews and will be shared on
this thread upon approval.

On Tue, Apr 26, 2022 at 11:24 PM Noam Rosenthal 
wrote:

> The summary says "payload list included below" - I can't find it though...
> is the list included in one of the links?
>
> On Tuesday, April 26, 2022 at 4:03:11 PM UTC+3 mike...@chromium.org wrote:
>
>> On 4/26/22 8:14 AM, Anne van Kesteren wrote:
>> > On Tue, Apr 26, 2022 at 1:59 PM Daisuke Enomoto 
>> wrote:
>> >> Explainer
>> >>
>> >>
>> https://docs.google.com/document/d/1pvaMg7J5beBXD7trzHJH_MDULc_wRHLx40MFYAmjknE/edit
>> > This document isn't public.
>>
>> I just checked the settings, and it should be public now.
>>
>> > This particular technique has been discussed before, but there's a
>> > flaw which wasn't mentioned in this email. The idea assumes that all
>> > end users can access the same websites and also that all end users
>> > visit similar websites. Neither of those is a given and as such end
>> > users that for one reason or another only end up visiting one or two
>> > websites that use a "pervasive payload" could be vulnerable to attack.
>>
>>

-- 
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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYAOk3FhsDyBppMOOcAXN4DeRdXhzJN%2BDpUsHvCAoCGA7%3Dg%40mail.gmail.com.

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

2021-12-06 Thread Nidhi Jaju

Hi Joe,

I'm really sorry for the delay in my reply!
These changes will be shipped in Chrome 98.

Best regards,
Nidhi

On Wed, Dec 1, 2021 at 5:14 AM Joe Medley  wrote:

> In which version is this shipping?
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>  816-678-7195
> *If an API's not documented it doesn't exist.*
>
>
> On Wed, Nov 24, 2021 at 8:21 AM Chris Harrelson 
> wrote:
>
>> LGTM3
>>
>> On Wed, Nov 24, 2021 at 6:18 AM Mike West  wrote:
>>
>>> LGTM2.
>>>
>>> Given that this has landed in both DOM and Streams with support from
>>> Mozilla, and WebKit has tacitly expressed support via their implementation,
>>> this is a pretty reasonable thing for us to follow along with. Thanks for
>>> iterating with others in the ecosystem to land on something folks were
>>> happy with!
>>>
>>> -mike
>>>
>>>
>>> On Wed, Nov 24, 2021 at 11:06 AM Yoav Weiss 
>>> wrote:
>>>
>>>> LGTM1
>>>>
>>>> On Wed, Nov 24, 2021, 10:50 Nidhi Jaju  wrote:
>>>>
>>>>> On Wed, Nov 24, 2021 at 1:43 PM Yoav Weiss 
>>>>> wrote:
>>>>>
>>>>>> Thanks for addressing the TAG's feedback!
>>>>>>
>>>>>>
>>>>>> On Wednesday, November 24, 2021 at 8:57:12 AM UTC+1 Nidhi Jaju wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Another update: based on the feedback we received from TAG as
>>>>>>> previously mentioned, we decided to remove the abortReason from
>>>>>>> WritableStreamDefaultController which was initially proposed, and 
>>>>>>> instead
>>>>>>> add an "abort reason" property
>>>>>>> <https://dom.spec.whatwg.org/#abortsignal-abort-reason> to
>>>>>>> AbortSignal which was specced in
>>>>>>> https://github.com/whatwg/dom/pull/1027. Related to this on the
>>>>>>> interface side, the static AbortSignal.abort()
>>>>>>> <https://dom.spec.whatwg.org/#dom-abortsignal-abort> as well as the
>>>>>>> AbortController.abort()
>>>>>>> <https://dom.spec.whatwg.org/#dom-abortcontroller-abort> now take
>>>>>>> an optional reason argument. Gecko and WebKit folks and some developers
>>>>>>> have also expressed implementer's interest on the PR, and some have 
>>>>>>> gone on
>>>>>>> to update their browser implementation/polyfills already.
>>>>>>>
>>>>>>
>>>>>> Any specifics? Does this mean other browsers are now also shipping
>>>>>> AbortSignal for WritableStreams? Or did they just update their current
>>>>>> AbortSignal implementation with an "abort reason"?
>>>>>>
>>>>>
>>>>> Ah, sorry for the unclearness. I mean they (i.e. WebKit
>>>>> <https://github.com/WebKit/WebKit/commit/d354a8d80fbd702d13ea293d1462b19e2652ef66>,
>>>>> Deno
>>>>> <https://github.com/denoland/deno/commit/ccd730a8b77c188657ec15b5d096f62a24bd0be6>,
>>>>> and almost Node.js <https://github.com/nodejs/node/pull/40807>) have
>>>>> updated their current AbortSignal implementation with an "abort reason". 
>>>>> As
>>>>> far as I'm aware, the signals related to shipping AbortSignal for
>>>>> WritableStreams itself remain unchanged from earlier on in this thread.
>>>>>
>>>>
>>>> Makes sense, thanks for clarifying!
>>>>
>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> This was also integrated into the Streams standard in
>>>>>>> https://github.com/whatwg/streams/pull/1182. (FYI: the AbortSignal
>>>>>>> API is connected to various different standards, so there is also an
>>>>>>> ongoing effort to update those affected specs as well here
>>>>>>> <https://github.com/whatwg/dom/issues/1030>.)
>>>>>>>
>>>>>>> I would like to resume the intent process based on these updates.
>>>>>>> Please let me know if you have any questions or thoughts.
>>>>>>>
>>>>>>>

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

2021-11-24 Thread Nidhi Jaju

On Wed, Nov 24, 2021 at 1:43 PM Yoav Weiss  wrote:

> Thanks for addressing the TAG's feedback!
>
>
> On Wednesday, November 24, 2021 at 8:57:12 AM UTC+1 Nidhi Jaju wrote:
>
>> Hi all,
>>
>> Another update: based on the feedback we received from TAG as previously
>> mentioned, we decided to remove the abortReason from
>> WritableStreamDefaultController which was initially proposed, and instead
>> add an "abort reason" property
>> <https://dom.spec.whatwg.org/#abortsignal-abort-reason> to AbortSignal
>> which was specced in https://github.com/whatwg/dom/pull/1027. Related to
>> this on the interface side, the static AbortSignal.abort()
>> <https://dom.spec.whatwg.org/#dom-abortsignal-abort> as well as the
>> AbortController.abort()
>> <https://dom.spec.whatwg.org/#dom-abortcontroller-abort> now take an
>> optional reason argument. Gecko and WebKit folks and some developers have
>> also expressed implementer's interest on the PR, and some have gone on to
>> update their browser implementation/polyfills already.
>>
>
> Any specifics? Does this mean other browsers are now also shipping
> AbortSignal for WritableStreams? Or did they just update their current
> AbortSignal implementation with an "abort reason"?
>

Ah, sorry for the unclearness. I mean they (i.e. WebKit
<https://github.com/WebKit/WebKit/commit/d354a8d80fbd702d13ea293d1462b19e2652ef66>,
Deno
<https://github.com/denoland/deno/commit/ccd730a8b77c188657ec15b5d096f62a24bd0be6>,
and almost Node.js <https://github.com/nodejs/node/pull/40807>) have
updated their current AbortSignal implementation with an "abort reason". As
far as I'm aware, the signals related to shipping AbortSignal for
WritableStreams itself remain unchanged from earlier on in this thread.


>
>
>>
>> This was also integrated into the Streams standard in
>> https://github.com/whatwg/streams/pull/1182. (FYI: the AbortSignal API
>> is connected to various different standards, so there is also an ongoing
>> effort to update those affected specs as well here
>> <https://github.com/whatwg/dom/issues/1030>.)
>>
>> I would like to resume the intent process based on these updates. Please
>> let me know if you have any questions or thoughts.
>>
>> Thank you!
>>
>> Best regards,
>> Nidhi
>>
>> On Thu, Oct 7, 2021 at 1:11 PM Yoav Weiss  wrote:
>>
>>> After talking to Nidhi offline, we can consider this intent on hold
>>> until the feedback is addressed.
>>>
>>> On Thursday, September 16, 2021 at 4:01:29 AM UTC+2 Nidhi Jaju wrote:
>>>
>>>> Hi,
>>>>
>>>> Just as an update, we have received some feedback on our TAG review (
>>>> https://github.com/w3ctag/design-reviews/issues/672#issuecomment-919578419),
>>>> and hence we are having some discussions and deciding on next best steps
>>>> accordingly.
>>>>
>>>> Best regards,
>>>> Nidhi
>>>>
>>>> On Fri, Sep 3, 2021 at 10:44 AM Nidhi Jaju 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Sep 3, 2021 at 4:35 AM Reilly Grant 
>>>>> wrote:
>>>>>
>>>>>> The Web Serial API is also interested in this capability. See the
>>>>>> note on the abort algorithm when initializing the WritableStream
>>>>>> <https://wicg.github.io/serial/#writable-attribute>.
>>>>>> Reilly Grant | Software Engineer | reil...@chromium.org | Google
>>>>>> Chrome <https://www.google.com/chrome>
>>>>>>
>>>>>>
>>>>>> On Thu, Sep 2, 2021 at 12:32 PM Chris Harrelson <
>>>>>> chris...@chromium.org> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Sep 1, 2021 at 8:22 PM Nidhi Jaju 
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Sep 1, 2021 at 10:54 PM Alex Russell <
>>>>>>>> slightly...@chromium.org> wrote:
>>>>>>>>
>>>>>>>>> Incremental features often benefit from TAG guidance. I'd feel
>>>>>>>>> better if this intent at least cited prior TAG reviews in this area or
>>>>>>>>> filed an FYI (with potential for TAG to request full review).
>>>>>>>>>
>>>>>>>>> If i

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

2021-11-23 Thread Nidhi Jaju

Hi all,

Another update: based on the feedback we received from TAG as previously
mentioned, we decided to remove the abortReason from
WritableStreamDefaultController which was initially proposed, and instead
add an "abort reason" property
<https://dom.spec.whatwg.org/#abortsignal-abort-reason> to AbortSignal
which was specced in https://github.com/whatwg/dom/pull/1027. Related to
this on the interface side, the static AbortSignal.abort()
<https://dom.spec.whatwg.org/#dom-abortsignal-abort> as well as the
AbortController.abort()
<https://dom.spec.whatwg.org/#dom-abortcontroller-abort> now take an
optional reason argument. Gecko and WebKit folks and some developers have
also expressed implementer's interest on the PR, and some have gone on to
update their browser implementation/polyfills already.

This was also integrated into the Streams standard in
https://github.com/whatwg/streams/pull/1182. (FYI: the AbortSignal API is
connected to various different standards, so there is also an ongoing
effort to update those affected specs as well here
<https://github.com/whatwg/dom/issues/1030>.)

I would like to resume the intent process based on these updates. Please
let me know if you have any questions or thoughts.

Thank you!

Best regards,
Nidhi

On Thu, Oct 7, 2021 at 1:11 PM Yoav Weiss  wrote:

> After talking to Nidhi offline, we can consider this intent on hold until
> the feedback is addressed.
>
> On Thursday, September 16, 2021 at 4:01:29 AM UTC+2 Nidhi Jaju wrote:
>
>> Hi,
>>
>> Just as an update, we have received some feedback on our TAG review (
>> https://github.com/w3ctag/design-reviews/issues/672#issuecomment-919578419),
>> and hence we are having some discussions and deciding on next best steps
>> accordingly.
>>
>> Best regards,
>> Nidhi
>>
>> On Fri, Sep 3, 2021 at 10:44 AM Nidhi Jaju 
>> wrote:
>>
>>>
>>>
>>> On Fri, Sep 3, 2021 at 4:35 AM Reilly Grant 
>>> wrote:
>>>
>>>> The Web Serial API is also interested in this capability. See the note
>>>> on the abort algorithm when initializing the WritableStream
>>>> <https://wicg.github.io/serial/#writable-attribute>.
>>>> Reilly Grant | Software Engineer | reil...@chromium.org | Google Chrome
>>>> <https://www.google.com/chrome>
>>>>
>>>>
>>>> On Thu, Sep 2, 2021 at 12:32 PM Chris Harrelson 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Sep 1, 2021 at 8:22 PM Nidhi Jaju 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Sep 1, 2021 at 10:54 PM Alex Russell <
>>>>>> slightly...@chromium.org> wrote:
>>>>>>
>>>>>>> Incremental features often benefit from TAG guidance. I'd feel
>>>>>>> better if this intent at least cited prior TAG reviews in this area or
>>>>>>> filed an FYI (with potential for TAG to request full review).
>>>>>>>
>>>>>>> If it was covered in a previous review of WritableStreams, that
>>>>>>> would also be good to know.
>>>>>>>
>>>>>>
>>>>>> This feature wasn't covered in a previous review of WritableStreams,
>>>>>> so I have filed a new TAG review:
>>>>>> https://github.com/w3ctag/design-reviews/issues/672
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Wed, Sep 1, 2021, 2:28 PM Yoav Weiss 
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Aug 31, 2021 at 5:14 PM Nidhi Jaju 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Contact emailsnidhij...@chromium.org, ri...@chromium.org,
>>>>>>>>> yhir...@chromium.org
>>>>>>>>>
>>>>>>>>> Explainer
>>>>>>>>> https://github.com/whatwg/streams/blob/main/writable-stream-abort-signal-explainer.md
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Specification
>>>>>>>>> https://streams.spec.whatwg.org/#writablestreamdefaultcontroller-signal
>>>>>>>>>
>>>>>>>>> Summary
>>>>>>>>>
>>>>>>>>> The s

[blink-dev] PSA: Readable Byte Streams updates in Blink Implementation

2021-10-13 Thread Nidhi Jaju

Hi all,

*(If you do not work with readable byte streams, you can ignore this.)*

We have recently submitted some CLs for updating readable byte streams in
the Blink Implementation based on the latest spec changes in the Streams
API standard. These updates fix various issues related to readable byte
streams and improve standards compliance.

These changes include:
- respondWithNewView(newView) can now be called with a new view that is
smaller than the BYOB request's view
- respondWithNewView() cannot be called with a non-empty view when the
stream is closed
- respondWithNewView(newView) must now be called with a view whose buffer
has the same length as that of the BYOB request
- enqueue(chunk) and respondWithNewView(newView) now checks that the given
view's buffer is actually transferable
- enqueue() and respond() now checks that the BYOB request's view has not
been transferred
- enqueue(), respond() and respondWithNewView() immediately invalidates the
BYOB request
- Any pending BYOB reads are now resolved immediately on cancel()
- enqueue() now discards the BYOB request if it was auto-allocated

(For reference:
https://chromium-review.googlesource.com/c/chromium/src/+/3216570,
https://chromium-review.googlesource.com/c/chromium/src/+/3216778, and
https://chromium-review.googlesource.com/c/chromium/src/+/3213786)

Cheers,
Nidhi Jaju

-- 
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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYAN7VSVpdd5v8mK0otwRF6-w9ezsP3dyqm-wO-bWS%3DKvSQ%40mail.gmail.com.

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

2021-09-15 Thread Nidhi Jaju

Hi,

Just as an update, we have received some feedback on our TAG review (
https://github.com/w3ctag/design-reviews/issues/672#issuecomment-919578419),
and hence we are having some discussions and deciding on next best steps
accordingly.

Best regards,
Nidhi

On Fri, Sep 3, 2021 at 10:44 AM Nidhi Jaju  wrote:

>
>
> On Fri, Sep 3, 2021 at 4:35 AM Reilly Grant  wrote:
>
>> The Web Serial API is also interested in this capability. See the note on
>> the abort algorithm when initializing the WritableStream
>> <https://wicg.github.io/serial/#writable-attribute>.
>> Reilly Grant | Software Engineer | reil...@chromium.org | Google Chrome
>> <https://www.google.com/chrome>
>>
>>
>> On Thu, Sep 2, 2021 at 12:32 PM Chris Harrelson 
>> wrote:
>>
>>>
>>>
>>> On Wed, Sep 1, 2021 at 8:22 PM Nidhi Jaju 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Sep 1, 2021 at 10:54 PM Alex Russell 
>>>> wrote:
>>>>
>>>>> Incremental features often benefit from TAG guidance. I'd feel better
>>>>> if this intent at least cited prior TAG reviews in this area or filed an
>>>>> FYI (with potential for TAG to request full review).
>>>>>
>>>>> If it was covered in a previous review of WritableStreams, that would
>>>>> also be good to know.
>>>>>
>>>>
>>>> This feature wasn't covered in a previous review of WritableStreams, so
>>>> I have filed a new TAG review:
>>>> https://github.com/w3ctag/design-reviews/issues/672
>>>>
>>>>
>>>>>
>>>>> On Wed, Sep 1, 2021, 2:28 PM Yoav Weiss 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Aug 31, 2021 at 5:14 PM Nidhi Jaju 
>>>>>> wrote:
>>>>>>
>>>>>>> Contact emailsnidhij...@chromium.org, ri...@chromium.org,
>>>>>>> yhir...@chromium.org
>>>>>>>
>>>>>>> Explainer
>>>>>>> https://github.com/whatwg/streams/blob/main/writable-stream-abort-signal-explainer.md
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Specification
>>>>>>> https://streams.spec.whatwg.org/#writablestreamdefaultcontroller-signal
>>>>>>>
>>>>>>> Summary
>>>>>>>
>>>>>>> The streams APIs provide ubiquitous, interoperable primitives for
>>>>>>> creating, composing, and consuming streams of data. This change permits 
>>>>>>> an
>>>>>>> underlying sink to rapidly abort an ongoing write or close when 
>>>>>>> requested
>>>>>>> by the writer.
>>>>>>>
>>>>>>>
>>>>>>> Previously, when writer.abort() was called, a long-running write
>>>>>>> would still have to continue to completion before the stream could be
>>>>>>> aborted. With this change, the write can be aborted immediately.
>>>>>>>
>>>>>>
>>>>>> Am I correct in assuming that the stream developer would have to
>>>>>> change their code in order for that to happen, and if they won't, the
>>>>>> current behavior won't change?
>>>>>>
>>>>>
>>>> Yes, that's correct.
>>>>
>>>>
>>>>>>
>>>>>>> In addition to being exposed to streams authored in JavaScript, this
>>>>>>> facility will also be used by platform-provided streams such as
>>>>>>> WebTransport.
>>>>>>>
>>>>>>> Blink componentBlink>Network>StreamsAPI
>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ENetwork%3EStreamsAPI>
>>>>>>>
>>>>>>> TAG reviewNot needed as this is an incremental improvement to an
>>>>>>> existing feature.
>>>>>>>
>>>>>>> TAG review statusNot applicable
>>>>>>>
>>>>>>> Risks
>>>>>>> Interoperability and Compatibility
>>>>>>>
>>>>>>> Low risk because streams has already been standardised for a long
>>>>>>> time (since around 2014). Other browsers have

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

2021-09-02 Thread Nidhi Jaju

On Fri, Sep 3, 2021 at 4:35 AM Reilly Grant  wrote:

> The Web Serial API is also interested in this capability. See the note on
> the abort algorithm when initializing the WritableStream
> <https://wicg.github.io/serial/#writable-attribute>.
> Reilly Grant | Software Engineer | reil...@chromium.org | Google Chrome
> <https://www.google.com/chrome>
>
>
> On Thu, Sep 2, 2021 at 12:32 PM Chris Harrelson 
> wrote:
>
>>
>>
>> On Wed, Sep 1, 2021 at 8:22 PM Nidhi Jaju  wrote:
>>
>>>
>>>
>>> On Wed, Sep 1, 2021 at 10:54 PM Alex Russell 
>>> wrote:
>>>
>>>> Incremental features often benefit from TAG guidance. I'd feel better
>>>> if this intent at least cited prior TAG reviews in this area or filed an
>>>> FYI (with potential for TAG to request full review).
>>>>
>>>> If it was covered in a previous review of WritableStreams, that would
>>>> also be good to know.
>>>>
>>>
>>> This feature wasn't covered in a previous review of WritableStreams, so
>>> I have filed a new TAG review:
>>> https://github.com/w3ctag/design-reviews/issues/672
>>>
>>>
>>>>
>>>> On Wed, Sep 1, 2021, 2:28 PM Yoav Weiss  wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Aug 31, 2021 at 5:14 PM Nidhi Jaju 
>>>>> wrote:
>>>>>
>>>>>> Contact emailsnidhij...@chromium.org, ri...@chromium.org,
>>>>>> yhir...@chromium.org
>>>>>>
>>>>>> Explainer
>>>>>> https://github.com/whatwg/streams/blob/main/writable-stream-abort-signal-explainer.md
>>>>>>
>>>>>>
>>>>>
>>>>>>
>>>>>> Specification
>>>>>> https://streams.spec.whatwg.org/#writablestreamdefaultcontroller-signal
>>>>>>
>>>>>> Summary
>>>>>>
>>>>>> The streams APIs provide ubiquitous, interoperable primitives for
>>>>>> creating, composing, and consuming streams of data. This change permits 
>>>>>> an
>>>>>> underlying sink to rapidly abort an ongoing write or close when requested
>>>>>> by the writer.
>>>>>>
>>>>>>
>>>>>> Previously, when writer.abort() was called, a long-running write
>>>>>> would still have to continue to completion before the stream could be
>>>>>> aborted. With this change, the write can be aborted immediately.
>>>>>>
>>>>>
>>>>> Am I correct in assuming that the stream developer would have to
>>>>> change their code in order for that to happen, and if they won't, the
>>>>> current behavior won't change?
>>>>>
>>>>
>>> Yes, that's correct.
>>>
>>>
>>>>>
>>>>>> In addition to being exposed to streams authored in JavaScript, this
>>>>>> facility will also be used by platform-provided streams such as
>>>>>> WebTransport.
>>>>>>
>>>>>> Blink componentBlink>Network>StreamsAPI
>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ENetwork%3EStreamsAPI>
>>>>>>
>>>>>> TAG reviewNot needed as this is an incremental improvement to an
>>>>>> existing feature.
>>>>>>
>>>>>> TAG review statusNot applicable
>>>>>>
>>>>>> Risks
>>>>>> Interoperability and Compatibility
>>>>>>
>>>>>> Low risk because streams has already been standardised for a long
>>>>>> time (since around 2014). Other browsers have implemented other parts of
>>>>>> the standard, and they will most likely also adapt this feature as well
>>>>>> soon.
>>>>>>
>>>>>> Gecko: Positive (
>>>>>> https://github.com/whatwg/streams/pull/1132#issuecomment-867114529
>>>>>> <https://chromestatus.com/admin/features/launch/5698931422920704/5?intent=1>)
>>>>>> Mozilla is supportive of Streams but has not yet shipped WritableStream. 
>>>>>> It
>>>>>> is expected that they will include this feature when they do. They have
>>>>>> also expressed interest in implementing WebTransport, and therefore are
>>>>

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

2021-09-01 Thread Nidhi Jaju

On Wed, Sep 1, 2021 at 10:54 PM Alex Russell 
wrote:

> Incremental features often benefit from TAG guidance. I'd feel better if
> this intent at least cited prior TAG reviews in this area or filed an FYI
> (with potential for TAG to request full review).
>
> If it was covered in a previous review of WritableStreams, that would also
> be good to know.
>

This feature wasn't covered in a previous review of WritableStreams, so I
have filed a new TAG review:
https://github.com/w3ctag/design-reviews/issues/672


>
> On Wed, Sep 1, 2021, 2:28 PM Yoav Weiss  wrote:
>
>>
>>
>> On Tue, Aug 31, 2021 at 5:14 PM Nidhi Jaju 
>> wrote:
>>
>>> Contact emailsnidhij...@chromium.org, ri...@chromium.org,
>>> yhir...@chromium.org
>>>
>>> Explainer
>>> https://github.com/whatwg/streams/blob/main/writable-stream-abort-signal-explainer.md
>>>
>>>
>>
>>>
>>> Specification
>>> https://streams.spec.whatwg.org/#writablestreamdefaultcontroller-signal
>>>
>>> Summary
>>>
>>> The streams APIs provide ubiquitous, interoperable primitives for
>>> creating, composing, and consuming streams of data. This change permits an
>>> underlying sink to rapidly abort an ongoing write or close when requested
>>> by the writer.
>>>
>>>
>>> Previously, when writer.abort() was called, a long-running write would
>>> still have to continue to completion before the stream could be aborted.
>>> With this change, the write can be aborted immediately.
>>>
>>
>> Am I correct in assuming that the stream developer would have to change
>> their code in order for that to happen, and if they won't, the current
>> behavior won't change?
>>
>
Yes, that's correct.


>>
>>> In addition to being exposed to streams authored in JavaScript, this
>>> facility will also be used by platform-provided streams such as
>>> WebTransport.
>>>
>>> Blink componentBlink>Network>StreamsAPI
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ENetwork%3EStreamsAPI>
>>>
>>> TAG reviewNot needed as this is an incremental improvement to an
>>> existing feature.
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>> Interoperability and Compatibility
>>>
>>> Low risk because streams has already been standardised for a long time
>>> (since around 2014). Other browsers have implemented other parts of the
>>> standard, and they will most likely also adapt this feature as well soon.
>>>
>>> Gecko: Positive (
>>> https://github.com/whatwg/streams/pull/1132#issuecomment-867114529
>>> <https://chromestatus.com/admin/features/launch/5698931422920704/5?intent=1>)
>>> Mozilla is supportive of Streams but has not yet shipped WritableStream. It
>>> is expected that they will include this feature when they do. They have
>>> also expressed interest in implementing WebTransport, and therefore are
>>> supportive of this feature.
>>>
>>
>> While such comments don't typically count as a position, combining them
>> with https://github.com/mozilla/standards-positions/issues/167 seems
>> reasonable, given the size of this change.
>>
>>
>>>
>>> WebKit: No signal
>>>
>>
>> Have you reached out? https://bit.ly/blink-signals
>>
>
I have requested for WebKit's position here:
https://lists.webkit.org/pipermail/webkit-dev/2021-September/031977.html


>
>>
>>>
>>> Web developers: No signals
>>>
>>
>> Have you reached out? https://goo.gle/developer-signals
>>
>
Mattias Buelens has shown positive support here:
https://github.com/whatwg/streams/issues/1015#issuecomment-531188273
<https://github.com/whatwg/streams/issues/1015#issuecomment-531188273>


>
>>
>>>
>>> Ergonomics
>>>
>>> A lot of design efforts have been made into making the streams API easy
>>> to use. Additionally, this feature is only a small change to the existing
>>> streams API that developers are used to. An underlying sink which doesn't
>>> observe the controller.signal will continue to have the existing behavior.
>>>
>>>
>>> Debuggability
>>>
>>> No special support needed.
>>>
>>> Is this feature fully tested by web-platform-tests
>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>>> ?Yes
>>>
>

[blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

2021-08-31 Thread Nidhi Jaju

Contact emailsnidhij...@chromium.org, ri...@chromium.org,
yhir...@chromium.org

Explainer
https://github.com/whatwg/streams/blob/main/writable-stream-abort-signal-explainer.md

Specification
https://streams.spec.whatwg.org/#writablestreamdefaultcontroller-signal

Summary

The streams APIs provide ubiquitous, interoperable primitives for creating,
composing, and consuming streams of data. This change permits an underlying
sink to rapidly abort an ongoing write or close when requested by the
writer.

Previously, when writer.abort() was called, a long-running write would
still have to continue to completion before the stream could be aborted.
With this change, the write can be aborted immediately. In addition to
being exposed to streams authored in JavaScript, this facility will also be
used by platform-provided streams such as WebTransport.

Blink componentBlink>Network>StreamsAPI

TAG reviewNot needed as this is an incremental improvement to an existing
feature.

TAG review statusNot applicable

Risks
Interoperability and Compatibility

Low risk because streams has already been standardised for a long time
(since around 2014). Other browsers have implemented other parts of the
standard, and they will most likely also adapt this feature as well soon.

Gecko: Positive (
https://github.com/whatwg/streams/pull/1132#issuecomment-867114529
)
Mozilla is supportive of Streams but has not yet shipped WritableStream. It
is expected that they will include this feature when they do. They have
also expressed interest in implementing WebTransport, and therefore are
supportive of this feature.

WebKit: No signal

Web developers: No signals

Ergonomics

A lot of design efforts have been made into making the streams API easy to
use. Additionally, this feature is only a small change to the existing
streams API that developers are used to. An underlying sink which doesn't
observe the controller.signal will continue to have the existing behavior.

Debuggability

No special support needed.

Is this feature fully tested by web-platform-tests

?Yes

Flag name
Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1215992

Patch
https://chromium-review.googlesource.com/c/chromium/src/+/3127824

Estimated milestonesM95

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5698931422920704

This intent message was generated by Chrome Platform Status
.

--
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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYAP-Of819oOp4yq8vRdzx78UUCPj9YKJqx4ZwLj_YsN%3D-Q%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Zstd Content-Encoding

Re: [blink-dev] Intent to Ship: Zstd Content-Encoding

Re: [blink-dev] Intent to Ship: Zstd Content-Encoding

[blink-dev] Intent to Ship: Zstd Content-Encoding

Re: [blink-dev] Intent to Experiment: Zstd Content-Encoding

Re: [blink-dev] Intent to Experiment: Zstd Content-Encoding

[blink-dev] Intent to Experiment: Zstd Content-Encoding

Re: [blink-dev] Intent to Prototype: Zstd Content-Encoding

Re: [blink-dev] Intent to Prototype: Zstd Content-Encoding

[blink-dev] Intent to Prototype: Zstd Content-Encoding

Re: [blink-dev] Intent to Ship: BYOB support for Fetch

Re: [blink-dev] Intent to Ship: BYOB support for Fetch

[blink-dev] Intent to Ship: BYOB support for Fetch

[blink-dev] Intent to Prototype: BYOB support for Fetch

[blink-dev] PSA: Support for teeing readable byte streams

[blink-dev] PSA: Adding 'Set-Cookie' header to Fetch's forbidden header names

Re: [blink-dev] Intent to Experiment: Load common payloads from privacy-preserving single-keyed cache

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

[blink-dev] PSA: Readable Byte Streams updates in Blink Implementation

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

[blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

25 matches

Site Navigation

Mail list logo

Footer information