[webkit-dev] Request for position: Response.json() static method
The Response.json() static method permits constructing a Response object with the body populated with a JavaScript object serialized as JSON. Links: - Explainer: https://docs.google.com/document/d/1dTycWmyxLZNGTBW93fvtf1IQahx-vNwgu94yT1x9K50/edit - Spec: https://fetch.spec.whatwg.org/#ref-for-dom-response-json - ChromeStatus entry: https://chromestatus.com/feature/5197912798658560 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Request for feedback on CompressionStream and DecompressionStream
We are implementing the "deflate-raw" compression codec for compression streams. This is similar to "deflate" but lacks a header and footer. In other words, it is pure RFC1951, unlike "deflate" which is actually RFC1950, "ZLIB Compressed Data Format". The awkward naming is for compatibility with HTTP Content-Encodings. One of the major use cases for this is implementing the ZIP format, which otherwise requires some ugly hacks: https://github.com/WICG/compression/issues/25#issuecomment-850959782 This is a tiny addition, so I haven't created a new thread for it. Any feedback is welcome. Thanks, Adam Rice, Chromium On Thu, 13 Aug 2020 at 08:37, Ryosuke Niwa wrote: > Hi all, > > This is a very belated reply but what's being proposed seems > reasonable to us (Apple's WebKit team). We would like to know more > about use cases, and how they might be deployed in real websites / use > cases but we don't see any major issues with it. > > - R. Niwa > > On Wed, Nov 27, 2019 at 11:18 PM Thomas Steiner wrote: > > > > You can see DecompressionStream in action in unarchiver, this is the > relevant code snippet (run it in Chrome 79+ with the > chrome://flags/#native-file-system-api and the > chrome://flags/#enable-experimental-web-platform-features flags set). > > > > On Thu, Nov 28, 2019 at 6:07 AM Adam Rice wrote: > >> > >> I am trying to gauge feedback on compression streams with a view to > shipping them in Chromium. > >> > >> Very briefly, they are a way to do gzip and gunzip in the browser. Less > briefly, the explainer > https://github.com/WICG/compression/blob/master/explainer.md goes into > some detail of the how and why. The specification > https://wicg.github.io/compression/ gives verbose detail of how. You may > also find the W3C TAG review > https://github.com/w3ctag/design-reviews/issues/410 interesting. > > > > ___ > > webkit-dev mailing list > > webkit-dev@lists.webkit.org > > https://lists.webkit.org/mailman/listinfo/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] FYI: Chrome will block ports 989 and 990
Just letting you know that Chrome is going to block ports 989 (ftps-data) and port 990 (ftps) in version 93. This is to prevent cross-protocol attacks. See https://github.com/whatwg/fetch/pull/1250 for background. I think it would be good for users if WebKit also blocked these ports. There is an issue at https://bugs.webkit.org/show_bug.cgi?id=226971. Thanks, Adam Rice ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Request for position on transferable streams
Sorry, the link to the pull request should have been https://github.com/whatwg/streams/pull/1053. On Fri, 14 Aug 2020 at 11:56, Adam Rice wrote: > Transferable streams permit you to run code like worker.postMessage(stream, > [stream]) where stream is a ReadableStream, WritableStream or > TransformStream and have it do what you'd expect. The explainer > <https://github.com/whatwg/streams/blob/master/transferable-streams-explainer.md> > goes into more detail of why you'd want to do this, but briefly it provides > a convenient way to do thread-offloading for streams-using code. > > The pull-request for the standard is at > https://github.com/whatwg/streams/issues/276 and the web platform tests > are at https://github.com/web-platform-tests/wpt/pull/24546. > > Any and all feedback is welcome! > > Thanks, > Adam Rice, Chromium > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Request for position on transferable streams
Transferable streams permit you to run code like worker.postMessage(stream, [stream]) where stream is a ReadableStream, WritableStream or TransformStream and have it do what you'd expect. The explainer <https://github.com/whatwg/streams/blob/master/transferable-streams-explainer.md> goes into more detail of why you'd want to do this, but briefly it provides a convenient way to do thread-offloading for streams-using code. The pull-request for the standard is at https://github.com/whatwg/streams/issues/276 and the web platform tests are at https://github.com/web-platform-tests/wpt/pull/24546. Any and all feedback is welcome! Thanks, Adam Rice, Chromium ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Request for feedback on CompressionStream and DecompressionStream
I am trying to gauge feedback on compression streams with a view to shipping them in Chromium. Very briefly, they are a way to do gzip and gunzip in the browser. Less briefly, the explainer https://github.com/WICG/compression/blob/master/explainer.md goes into some detail of the how and why. The specification https://wicg.github.io/compression/ gives verbose detail of how. You may also find the W3C TAG review https://github.com/w3ctag/design-reviews/issues/410 interesting. Any and all feedback is welcome! FAQ: Q. Will this support brotli, zstd, etc.? A. Not yet. It's on the radar. Thanks, Adam Rice, Chromium ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
