Re: Mnot's Pub/Sub for the Web

On Wed, 23 Feb 2022, at 12:10 PM, Matthew Kerwin wrote:
> Hi all,
>
> On Wed, 23 Feb 2022 at 10:06, Seph Gentle <me@josephg.com> wrote:
>>
>> I'd be happy for it to be a GET query with options or something, but however we do it I think it would be much *cleaner* implemented as part of HTTP.
>
> Do you mean HTTP the semantic layer, or HTTP the transport layer? I
> assume you mean the former since you're talking about verbs and nouns.
> For the latter there are probably lessons to be gleaned from HTTP/2
> server push, especially its evolution during specification from a
> general-purpose reverse data flow to a specific cache priming/busting
> tool (to something nobody implemented).

Yep, the semantic layer. I'm happy to defer to the collective wisdom of the working group when it comes to figuring out the syntax for something like this. So long as we capture the semantic intent of "subscribe to changes in the named resource" in a sensible way.

>> I want it to be understandable by caches and middle boxes, rather than something sitting on top of HTTP in an idiosyncratic way.
>
> My concern is that those caches and middle boxes are the very reason
> it's hard to implement anything new at the HTTP layer (either one).
> Some of those boxes are ossified around HTTP/1.0 and will never
> update; many probably implement an approximation of /1.1, but any
> message that isn't the exact flavour of /1.1 they've been coded to
> handle will make them explode. To the point that they don't read the
> version number, or sometimes even the entire method, in the request
> line.

How well do server-sent events work in practice through those systems? It seems like expanding on SSE might be a reasonable approach:

- Keep using GET, rather than inventing another HTTP verb
- Add client headers to specify the client's intent - "I want to subscribe, not just fetch a single copy of the document".
- The server can use http-like framing for SSE
- This is implementable right now (we've certainly done so), using javascript + the streaming capabilities of the fetch() method in web browsers.

> Maybe there's a space to design something as an extension to HTTP/2
> and /3, since those intentionally don't route through legacy
> middleware, but then there's a fork of the HTTP semantic layer
> (version 1, and version 2+) which we've kind of avoided up until now.
> (Aside: changing from single-request uber-concatenation in H1 to
> persistent connections with many tiny blobs in H2 could have lead to a
> semantic shift, but it's hard to see if that's actually happening.)
>
> As always on the Internet, a layer has ossified so it's time to build
> upwards. As messy as that is. (something something H3 over UDP instead
> of IP..)

Yeah; I suspect we could make something which sits very cleanly on top of HTTP2's internal semantics. But its a shame very little of that is exposed to browser javascript. It makes it much harder to try things out without modifying the web browser itself.

Received on Friday, 25 February 2022 01:33:21 UTC