[TUHS] HTTP (was Re: Re: Research Datakit notes)

[Derek Fawcus <dfawcus+lists-tuhs@employees.org>]

On Tue, Jun 28, 2022 at 10:05:26AM -0700, Adam Thornton wrote:
> 
> And I think we already have the answer about what the abstraction is, albeit at an application rather than the kernel level.
> 
> To answer Rob's question: I think the abstraction is now much farther up the stack.  To a pretty good first approximation, almost all applications simply definte their own semantics on top of HTTP(S) (OK, OK, Websockets muddy the waters again) and three-to-five verbs.  There's an incantation to establish a circuit (or a "session" if you're under the age of 50, I guess), and then you GET, DELETE, and at least one of PUT/POST/PATCH, for "read", "unlink", and "write".  This does seem to be a more record-oriented (kids these days get snippy if you call them "records" rather than "objects" but w/e) format than a stream of bytes (or at least you put an abstraction layer in between your records and the stream-of-octets that's happening).

Yes it is effectively records, or RPCs w/o state between requests.  So akin to DNS queries over UDP, rather than DNS queries over TCP.

As the whole HTTP model allows for proxies, at which point the request (GET, HEAD, POST, etc) includes
an endpoint address (DNS name and port) and path at that endpoint.  Having 'session' state is built at
a level above HTTP, by cookies or redirecting to magic URIs encoding the session ID after the query (the '?').

The fact that this all happens to run over a TCP connection, simply means that we have stacked sets of
VCs.  An application VC on top of a connectionless HTTP on top of a TCP 'VC'.  One could argue that
Websockets simplifies this by ripping out the HTTP layer, and having the top VC then just being message
framing within the TCP session.

(Ignoring for the moment TLS on top of TCP, or HTTP/3 being on top of QUIC, hence UDP)

> This is certainly not efficient at a wire protocol level, but it's a fairly small cognitive burden for people who just want to write applications that communicate with each other.

Sort of, in that I recently investigated the Go HTTP client/server APIs as someone was asking us about 
implementing a MiTM HTTP(S) "firewall".  Depending upon how one deals with it, it hides the VCs and exposes
the connectionless RPCs.

With such a MiTM in place, the 'nice' RPC in a session is effectivly forced back to the 'nasty' RPC in datagrams, even though the endpoints may be unaware, but they already include the whole datagram remote address in the request.  Responses come back by 'magic' without explicit address.

So maybe from that perspective one could model HTTP request/response as RPCs over SVCs, those being raised and torn down for each exchange.

DF