LGTM to experiment from 117 to 122 inclusive.

(Good luck, looks cool!)

On 7/25/23 9:52 PM, Tsuyoshi Horo wrote:


        Contact emails


        h...@chromium.org, pmee...@chromium.org,
        yoavwe...@chromium.org, kenjibah...@chromium.org


        Explainer


        https://github.com/WICG/compression-dictionary-transport


        Specification


        https://github.com/WICG/compression-dictionary-transport


        Design docs



        
https://docs.google.com/document/d/1IcRHLv-e9boECgPA5J4t8NDv9FPHDGgn0C12kfBgANg/edit
        https://github.com/WICG/compression-dictionary-transport
        
https://datatracker.ietf.org/doc/draft-meenan-httpbis-compression-dictionary


        Summary


        This feature adds support for using designated previous
        responses, as an external dictionary for Brotli-compressing
        HTTP responses.



        Blink component


        Blink>Network
        
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ENetwork>


        TAG review


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


        TAG review status


        Pending


        Risks




        Interoperability and Compatibility


        Interoperability and Compatibility risk are low. This feature
        introduces a new compression method for transporting resources
        over HTTP. Web sites can know the browser support for the new
        feature by checking
        `document.createElement('link').relList.supports('dictionary')`.
        Also web servers can know the browser support by checking the
        `Accept-Encoding` request header and the new
        `Use-As-Dictionary` request header. This feature is an opt-in
        feature. And the dictionary storage is isolated using the top
        level site and the frame origin as the key. That means, if
        there is no dictionary registered for the site, the behavior
        of Chrome will not change while browsing the site. Also this
        feature is usable only on secure-context. So this feature will
        not increase the risk of non-supporting network proxies
        misunderstanding the content’s encoding.



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

        /WebKit/: No signal
        (https://github.com/WebKit/standards-positions/issues/160)

        /Web developers/: No signals

        /Other signals/:


        Ergonomics


        To reduce memory usage in network services, dictionary
        metadata is stored in a database on disk. And to avoid
        performance degradation for normal requests that do not use a
        dictionary, the reading of this metadata is designed not to
        block network requests. In other words, if the reading of
        metadata from the database is not completed before the request
        header is ready to be sent to the server, the dictionary may
        not be used even if it is already registered in the database.



        Activation


        To adopt this feature, web developers need to make changes in
        their web servers. Currently there is no major server
        softwares which supports compression dictionaries.



        Security


        Chrome registers the response as a dictionary only when the
        response is CORS-readable from the document origin. Also we
        use a registered dictionary to decompress the response only
        when the response is CORS-readable from the document origin.
        Additionally, the dictionary and the compressed resource are
        required to be from the same origin as each other. So this
        should not introduce any new attack vector of stealing
        information. The dictionaries are partitioned with the storage
        cache and are cleared whenever cookies or cache is cleared to
        ensure that the dictionaries can not be abused as a tracking
        vector.



        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


        We would like to collect feedback on the Compression
        Dictionary Transport feature of API design. We would also like
        to run some experiments using this feature to measure its
        performance impact.


        Ongoing technical constraints


        None



        Debuggability


        We have introduced chrome://net-internals/#sharedDictionary.
        Using it, web developers can manage the registered
        dictionaries. Also web developers can check the related HTTP
        request and response headers (Use-As-Dictionary,
        Sec-Available-Dictionary, Accept-Encoding, Content-Encoding)
        using DevTools' Network tab.



        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. We will rewrite some browser_tests to WPT.




        Flag name on chrome://flags


        chrome://flags/#enable-compression-dictionary-transport-backend
        chrome://flags/#enable-compression-dictionary-transport


        Finch feature name


        CompressionDictionaryTransportBackend
        CompressionDictionaryTransport


        Requires code in //chrome?


        True


        Tracking bug


        https://crbug.com/1413922


        Launch bug


        https://launch.corp.google.com/launch/4266286


        Estimated milestones


        OriginTrial desktop last        122
        OriginTrial desktop first       117

        OriginTrial Android last        122
        OriginTrial Android first       117



        Link to entry on the Chrome Platform Status


        https://chromestatus.com/feature/5124977788977152


        Links to previous Intent discussions


        Intent to prototype:
        
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADk0S-Vb1ON2XT2%2BBP27tJ4ivjgyu63jcd667am4TwcVFGsbuw%40mail.gmail.com

        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/CADk0S-WyukWVPpFMFYSWVZ1%2BOuXVjtNfWiCqKvDYcdRwaApZLA%40mail.gmail.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADk0S-WyukWVPpFMFYSWVZ1%2BOuXVjtNfWiCqKvDYcdRwaApZLA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f161f75c-7786-f4a3-1bb2-b8813577451b%40chromium.org.

Reply via email to