Feedback on the Fetch spec additions #202

New Issue

claunia · 2026-01-29T20:39:47Z

claunia commented

2026-01-29 20:39:47 +00:00

Originally created by @yoavweiss on GitHub (Nov 17, 2017).

I'd like to provide some preliminary feedback on the Fetch spec patch.

First of all, thanks for working on Shared Brotli! I'm super excited about the possibilities :)

High level comments:

The entire approach for the protocol would highly benefit from an explainer document detailing in high-level what are the use cases that the protocol tackles, what it looks like, how it works, etc.
Integration of the protocol's processing with Fetch is great, but you probably also need an IETF draft to describe the headers and the mechanism. Also, Fetch implies that this protocol is only relevant to browsers, and doesn't cover other HTTP clients. Is that the case?

Practical comments:

How does the server know what dictionaries the client has? AFAICT there's no mechanism for the client to publish available dictionaries for a certain domain. Also, depending on the use-case, publishing such a list may not be feasible.
It's not immediately clear what's done with the SRI info. Is it just for validation purposes, or is it used for caching in some way?
The parts about recursive-sbr are not clear. IIUC, that's used to update a dictionary from a previous dictionary. If so, why is Accept-encoding: sbr forbidden? How does the server know to provide an sbr resource in this case?

Originally created by @yoavweiss on GitHub (Nov 17, 2017). I'd like to provide some preliminary feedback on the [Fetch spec patch](https://github.com/google/brotli/blob/master/fetch-spec/shared-brotli-fetch-spec.txt). First of all, thanks for working on Shared Brotli! I'm super excited about the possibilities :) High level comments: * The entire approach for the protocol would highly benefit from an explainer document detailing in high-level what are the use cases that the protocol tackles, what it looks like, how it works, etc. * Integration of the protocol's processing with Fetch is great, but you probably also need an IETF draft to describe the headers and the mechanism. Also, Fetch implies that this protocol is only relevant to browsers, and doesn't cover other HTTP clients. Is that the case? Practical comments: * How does the server know what dictionaries the client has? AFAICT there's no mechanism for the client to publish available dictionaries for a certain domain. Also, depending on the use-case, publishing such a list may not be feasible. * It's not immediately clear what's done with the SRI info. Is it just for validation purposes, or is it used for caching in some way? * The parts about `recursive-sbr` are not clear. IIUC, that's used to update a dictionary from a previous dictionary. If so, why is `Accept-encoding: sbr` forbidden? How does the server know to provide an sbr resource in this case?

claunia commented

2026-01-29 20:39:48 +00:00

@lvandeve commented on GitHub (Nov 17, 2017):

Thank you very much Yoav, that's super helpful!

The focus of this fetch spec is indeed on browser implementation, but the concept is not supposed to be irrelevant for other clients.

About publishing dictionaries: indeed the client does not tell the server which it has, instead the server provides the URL of the dictionary, and the client caches it. This is good when the client then requests other pages which use the same dictionary.
When using a previous document as dictionary for a next document, the server should know that the client already has this previous document since it sent it before during this session. Does the latter sound feasible?

About recursive-sbr: the dictionary itself can be compressed with for example br. This is to prevent dictionaries fetching other dictionaries fetching other dictionaries and so on. Good point about updating dictionary from other dictionary though. Maybe it makes more sense to allow some recursion but limit the depth.

@lvandeve commented on GitHub (Nov 17, 2017): Thank you very much Yoav, that's super helpful! The focus of this fetch spec is indeed on browser implementation, but the concept is not supposed to be irrelevant for other clients. About publishing dictionaries: indeed the client does not tell the server which it has, instead the server provides the URL of the dictionary, and the client caches it. This is good when the client then requests other pages which use the same dictionary. When using a previous document as dictionary for a next document, the server should know that the client already has this previous document since it sent it before during this session. Does the latter sound feasible? About recursive-sbr: the dictionary itself can be compressed with for example `br`. This is to prevent dictionaries fetching other dictionaries fetching other dictionaries and so on. Good point about updating dictionary from other dictionary though. Maybe it makes more sense to allow some recursion but limit the depth.

claunia commented

2026-01-29 20:39:48 +00:00

@yoavweiss commented on GitHub (Nov 21, 2017):

About publishing dictionaries: indeed the client does not tell the server which it has, instead the server provides the URL of the dictionary, and the client caches it. This is good when the client then requests other pages which use the same dictionary.
When using a previous document as dictionary for a next document, the server should know that the client already has this previous document since it sent it before during this session. Does the latter sound feasible?

That seems like something that will be hard to deploy. The server has to keep track of all past resources and their client side cacheability in order to know which dictionary to use. (Maybe Cache Digests can help a bit here...) It also seems like something that will result in breakage if the server and the client caches ever get out of sync.

Even on the same connection, use of URLs would mean that the browser would have to get the resources from the disk cache in order to use them as dictionaries. What happens when they are not cacheable?

@yoavweiss commented on GitHub (Nov 21, 2017): > About publishing dictionaries: indeed the client does not tell the server which it has, instead the server provides the URL of the dictionary, and the client caches it. This is good when the client then requests other pages which use the same dictionary. > When using a previous document as dictionary for a next document, the server should know that the client already has this previous document since it sent it before during this session. Does the latter sound feasible? That seems like something that will be hard to deploy. The server has to keep track of all past resources and their client side cacheability in order to know which dictionary to use. (Maybe Cache Digests can help a bit here...) It also seems like something that will result in breakage if the server and the client caches ever get out of sync. Even on the same connection, use of URLs would mean that the browser would have to get the resources from the disk cache in order to use them as dictionaries. What happens when they are not cacheable?

claunia commented

2026-01-29 20:39:48 +00:00

@lvandeve commented on GitHub (Nov 24, 2017):

The current design indeed tries to reuse the existing caching mechanism, the advantage is that it makes implementation simpler by reusing existing features. The alternative is to specify a new kind of cache (because no matter what, you must specify in some way that the client must keep the data somewhere, correct me if I'm wrong) with more strict requirements for keeping the data.

If the existing caching mechanism is used, the penalty when something is not properly cached, is that it will be requested by URL instead, so the compression benefit is gone. Ideally web servers would use a unique URL for every different resource that can be used as dictionary.

Any feedback on this is welcome

@lvandeve commented on GitHub (Nov 24, 2017): The current design indeed tries to reuse the existing caching mechanism, the advantage is that it makes implementation simpler by reusing existing features. The alternative is to specify a new kind of cache (because no matter what, you must specify in some way that the client must keep the data somewhere, correct me if I'm wrong) with more strict requirements for keeping the data. If the existing caching mechanism is used, the penalty when something is not properly cached, is that it will be requested by URL instead, so the compression benefit is gone. Ideally web servers would use a unique URL for every different resource that can be used as dictionary. Any feedback on this is welcome

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/brotli#202