Content-encoding may be fragile

[pmeenan]

Content-encoding is the most natural fit for the actual compression but it is likely to also cause adoption problems, at least in the short term.

It's not unusual for the serving path to consider content-encoding to be per-hop instead of end-to-end from the browser to the origin and unless the delta-encoding is being done by the leaf serving node, the sbr encoding is likely to be stripped out.

sequenceDiagram
Browser->>CDN: Accept-encoding: sbr, br, gzip
CDN->>Origin: Accept-encoding: gzip
Origin->>CDN: Content-encoding: gzip
CDN->>Browser: Content-encoding: br

If the actual encoding is done using other headers for negotiation but the content-type remains the same, then the compressed resources will be binary data and may cause other issues for middleboxes (i.e. with something like edge workers, they will be expecting to be processing text HTML, CSS or Javascript payloads). That could be workable for a given origin as long as they control the processing along their serving path.

One deployment model where it could work, but requires explicit support from both origins and CDNs is:

• Origin manages the bikeshed-use-as-dictionary: <path> response header
• CDN sees the header and stores the resource in a custom-dictionary cache with the appropriate hash
• Browser requests with sec-bikeshed-available-dictionary: and Accept-Encoding: sbr, br, gzip
• CDN checks cache for delta-compressed artifact for combination URL and dictionary
• On miss, CDN checks for cached uncompressed URL (or fetches from origin on full miss)
• If response is not already a delta-compressed artifact:
  • Check cache for requested dictionary
  • Compress response with requested dictionary (possibly as a background task for future requests)
  • Serve response to browser with Content-Encoding: sbr