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

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.

Received on Wednesday, 6 March 2019 22:41:49 UTC