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

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, <mt@lowentropy.net> wrote:

> On Wed, Mar 6, 2019, at 20:21, Stefan Eissing wrote:
> > 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).
>
> 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.
>
>