Re: Proposal: Adopt State Synchronization into HTTPbis

Thank you, Marius! These are good questions about how to format a 
Multiresponse:

On 10/9/24 12:20 AM, Marius Kleidl wrote:
> Regarding your example, Michael: Does the response body, which 
> contains the updates, adapt its syntax to the used HTTP protocol? Do 
> you suggest that subscriptions over HTTP/2 generate the updates as 
> additional HTTP/2 responses? If so, this would require subscriptions 
> to be implemented inside the HTTP client itself instead of being a 
> feature that a user can implement based upon existing and available 
> HTTP clients. In addition, this raises questions about how to handle 
> situations where the used protocol changes as requests and responses 
> are forwarded through proxies and gateways.

Yes, we would ideally format an H2 Multiresponse with native H2 frames. 
Here's an equivalent H2 version of my last H1 example:

       ┌─────────┐
       │ HEADERS │ :method = GET
       │ Frame   │ :path = /chat
       │         │ subscribe = timeout=10s
       └─────────┘
            │
            ▼
       ┌─────────┐
       │ HEADERS │ :status = 104
       │ Frame   │ subscribe = timeout=10s
       │         │ current-version = "3"
       └─────────┘
            │
            ▼
       ┌─────────┐
       │ HEADERS │ :status = 200
       │ Frame   │ version = "2"
       │         │ parents = "1a", "1b"
       │         │ content-type = application/json
       └─────────┘
            │
            ▼
       ┌─────────┐
       │  DATA   │ [{"text": "Hi, everyone!",
       │ Frame   │   "author": {"link": "/user/tommy"}}]
       └─────────┘
            │
            ▼
       ┌─────────┐
       │ HEADERS │ :status = 200
       │ Frame   │ version = "3"
       │         │ parents = "2"
       │         │ content-type = application/json
       │         │ merge-type = sync9
       └─────────┘
            │
            ▼
       ┌─────────┐
       │  DATA   │ [{"text": "Hi, everyone!",
       │ Frame   │   "author": {"link": "/user/tommy"}}
       │         │  {"text": "Yo!",
       │         │   "author": {"link": "/user/yobot"}]
       └─────────┘

You're absolutely right that this native version requires the client to 
be upgraded, and for proxies along the path to at least not interfere. 
If they don't, we can always fall back to the H1-style "shove it into 
the body" method. The trick is to know when it's safe to upgrade. We're 
currently extending cache-tests.fyi with some experiments to determine 
the best way to do this.

> I also wonder if we could reuse multipart responses for delivering 
> updates. The response to a subscription request would be a streamed 
> multipart response where each "part" is one update. The update can 
> include header fields as well as content, similar to your example. 
> Status codes in the update would not be directly possible, but I'm not 
> sure if that's a big loss.
Ah, yes this idea comes up frequently. The problem is that multipart 
relies on boundary conditions, which can be spoofed. Imagine an attacker 
learns that client C is getting updates streamed with boundary separator 
"====foo-bar-baz====". He can then try to find a way to mutate the 
resource in such a way to include that boundary separator in an update 
being sent to the client, and thus sneak fake data in.
> All in all, I enjoy the idea, but think that we can achieve this 
> already with the existing features we have.

I'm glad. I enjoy the idea, too. We're re-using features where possible. 
However, although SSE provides updates, it doesn't provide the semantics 
of "the resource is changing state", and doesn't even support binary, so 
it won't work for updating images. Multipart is tempting to re-use in 
Multiresponses, but has the boundary issue.

Michael