braid-org / braid-spec

Working area for Braid extensions to HTTP
https://braid.org
233 stars 16 forks source link

Compression or inheritence for headers #116

Open toomim opened 1 year ago

toomim commented 1 year ago

There is a lot of redundancy in headers for Braid subscriptions:

Example:

HTTP/1.1 209 Subscription
transfer-encoding: chunked
content-type: text/plain
merge-type: sharejs-ot
current-version: "ABC"
version: "B"
patches: 1

patch-type: ot-text-unicode    <-- redundant
patch-length: 7

[1,"b"]

content-type: text/plain       <-- redundant
merge-type: sharejs-ot         <-- redundant
patches: 1                     <-- redundant
version: "C"

patch-type: ot-text-unicode    <-- redundant
patch-length: 7

[2,"c"]

content-type: text/plain       <-- redundant
merge-type: sharejs-ot         <-- redundant
patches: 1                     <-- redundant
version: "D"

patch-type: ot-text-unicode    <-- redundant
patch-length: 7

[3,"d"]

This has been cropping up in other issues, notably: https://github.com/braid-org/braid-spec/issues/106

I currently see three ways to address this.

(1.) Updates could inherit the headers from previous updates by default, and then override any that should be different.

(2.) Patches could inherit the headers from the higher-level updates. Specifically, this is the proposal in https://github.com/braid-org/braid-spec/issues/106, which would let you specify the Patch-Type as a top-level header in a subscription, that all patches would inherit from by default.

(3.) Use HTTP/2 header compression (called HPACK) to reduce redundancy in general.

In summary, this boils down to:

  1. Use HPACK in HTTP/2, or:
  2. Define an inheritance process
    1. Across time, inheriting from the past
    2. Across hierarchy, inheriting from higher levels in the hierarchy

(Note that I'm presuming we're moving from a 3-level hierarchy to a 2-level hierarchy, as articulated here.)