Subject: Fwd: New Version Notification for draft-thomson-http-hx-uri-00.txt

From: "Martin Thomson" <[email-masked]>
Date: Mon, 04 Mar 2019 21:27:52 -0500

This is a crazy idea that has been brewing for a while.  This describes an identification scheme that might allow for some interesting optimizations of common API patterns.  Hopefully there is enough in the draft to stimulate thoughts about how HTTP might evolve.

Though it touches on the a common concept, this is not related at all to the signed exchanges work.

----- Original message -----
From: [email-masked]
To: Martin Thomson <[email-masked]>
Subject: New Version Notification for draft-thomson-http-hx-uri-00.txt
Date: Tuesday, March 05, 2019 13:23

A new version of I-D, draft-thomson-http-hx-uri-00.txt
has been successfully submitted by Martin Thomson and posted to the
IETF repository.

Name:		draft-thomson-http-hx-uri
Revision:	00
Title:		Identifying HTTP Exchanges with URIs
Document date:	2019-03-05
Group:		Individual Submission
Pages:		18
URL:            https://www.ietf.org/internet-drafts/draft-thomson-http-hx-uri-00.txt
Status:         https://datatracker.ietf.org/doc/draft-thomson-http-hx-uri/
Htmlized:       https://tools.ietf.org/html/draft-thomson-http-hx-uri-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-thomson-http-hx-uri

Abstract:
   URI schemes are defined that enable identification of HTTP exchanges,
   or parts of those exchanges.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 6 Mar 2019 10:17:29 +0100

> Am 05.03.2019 um 03:27 schrieb Martin Thomson <[email-masked]>:
> 

Wild and interesting. Looking at this from a server perspective:

This seems to assume that the connection, as seen by the client, looks the same on the server component processing this. At least in order to identify 'previous' requests. This is problematic in clusters, ssl terminators, and reverse proxies (connections to backend may come and go during a the lifetime of a frontend connection).

The references seem to go back in time only, at least in the examples. This would require a server to keep a lot of information about previous requests available. It would be much easier to process hx: uris that refer to requests in the future. So, a client would build up a sort of quantum state of hx: uris in the server (or an intermediate) and the real request(s) afterwards collapses it. This could at least work in HTTP/2(+).

Cheers,
Stefan

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 06 Mar 2019 17:41:27 -0500

On Wed, Mar 6, 2019, at 20:21, Stefan Eissing wrote:
> This seems to assume that the connection, as seen by the client, looks 
> the same on the server component processing this. At least in order to 
> identify 'previous' requests. This is problematic in clusters, ssl 
> terminators, and reverse proxies (connections to backend may come and 
> go during a the lifetime of a frontend connection).

Yes, the costs for a server are non-trivial.  I'd probably go so far as to say that the problems scale with your server deployment - in a bad way.  Particularly when requests attempt to reference requests that get sprayed all over a cluster.  It will depend a lot on your deployment as to whether supporting this is feasible.  But the idea is intended only as a fairly narrowly targeted solution.  It requires coordination with the server, as well as support in the formats that are exchanged.  

Roberto has an idea for providing affinity hints that might help load balancers and the like identify where requests need to be given similar routing.  That comes from wanting to do things like have video chunks all come from the same back end, but it might help here as well.
 
> The references seem to go back in time only, at least in the examples. 
> This would require a server to keep a lot of information about previous 
> requests available. It would be much easier to process hx: uris that 
> refer to requests in the future. So, a client would build up a sort of 
> quantum state of hx: uris in the server (or an intermediate) and the 
> real request(s) afterwards collapses it. This could at least work in 
> HTTP/2(+).

Yeah, I really don't see this as being very workable pre-h2.

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 6 Mar 2019 23:56:06 +0000

The thought that occurred to me was  was to embed the hx and hxr URIs in a
document that is uploaded as an atomic chain to a server.

Is that what you're discussing here?

On Wed, 6 Mar 2019, 22:45 Martin Thomson, <[email-masked]> wrote:

> Yes, the costs for a server are non-trivial.  I'd probably go so far as to
> say that the problems scale with your server deployment - in a bad way.
> Particularly when requests attempt to reference requests that get sprayed
> all over a cluster.  It will depend a lot on your deployment as to whether
> supporting this is feasible.  But the idea is intended only as a fairly
> narrowly targeted solution.  It requires coordination with the server, as
> well as support in the formats that are exchanged.
>
> Roberto has an idea for providing affinity hints that might help load
> balancers and the like identify where requests need to be given similar
> routing.  That comes from wanting to do things like have video chunks all
> come from the same back end, but it might help here as well.
>

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 06 Mar 2019 19:11:09 -0500

On Thu, Mar 7, 2019, at 10:59, Lucas Pardue wrote:
> The thought that occurred to me was was to embed the hx and hxr URIs in 
> a document that is uploaded as an atomic chain to a server. 
> 

Say more?  If you are talking about a single request, that might not be so advantageous.  This was really about managing dependency chains between requests without paying round trips.

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 7 Mar 2019 23:48:54 +0000

Ok so this is half-baked, and I didn't think about how to express bodies in
the document, but I imagined a Hierarchical Document consisting of hx
links. These are a series of steps the client wishes to perform against an
API. This articulates a set of conditinal actions which are dependent on
the previous step. So for instance, with HTTP/2

1) create object as if POST
2) let location be hx:///1/a/h/location?201
3) if location, modifying object at location as if POST
4) let hx:///3/s/
5) if status 2xx
6) modifying object at location as if POST
7) let status be hx:///5/s
8) if status 2xx
9) POST pizza order

A server that processes the document and completes all conditions will
return 2xx, any failure will lead to 4xx or 5xx. A client submits the
document and waits for the "final response".

Now, having written that, I see that I am unclear how hx and http(s) scheme
are supposed to be mixed with a single HTTP connection, or if that is
indeed the intent at all.

Lucas

On Thu, 7 Mar 2019, 00:14 Martin Thomson, <[email-masked]> wrote:

> Say more?  If you are talking about a single request, that might not be so
> advantageous.  This was really about managing dependency chains between
> requests without paying round trips.
>
>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 8 Mar 2019 17:06:27 +1100

We always knew you had a wild side, Martin.

> On 7 Mar 2019, at 9:41 am, Martin Thomson <[email-masked]> wrote:
> 

I tend to agree with Lucas here; this is a deal-killer for any kind of production site that uses a reverse proxy, CDN, or load balancer. It feels very "un-HTTP."

I think the logical direction to go would be to have the client give each request that it might want to reference in the future a UUID (or similar).

Also, I do wonder about having these URIs come in at the payload level; if they were referring to representations, you'd be able to talk more about what the application care about (e.g., consider the case of a 304 or a 206). 

See also <https://httpwg.org/specs/rfc7231.html#identification>; it's worth thinking about how these interact.

--
Mark Nottingham   https://www.mnot.net/

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 11 Mar 2019 19:40:59 -0400

On Fri, Mar 8, 2019, at 17:10, Mark Nottingham wrote:
> I think the logical direction to go would be to have the client give 
> each request that it might want to reference in the future a UUID (or 
> similar).

I'm less sure about this.  The key is to establish some expectation that an interaction will be referred to, but we might do that using other methods.  That said, the properties you are looking for are end-to-end, so the mechanism I chose is probably a poor fit for that.
 
> Also, I do wonder about having these URIs come in at the payload level; 
> if they were referring to representations, you'd be able to talk more 
> about what the application care about (e.g., consider the case of a 304 
> or a 206). 

Yeah, I spent some time trying to think through those and concluded that if I started to pull on that thread I'd never finish.  But it is probably better overall to identify the representation rather than the payload.