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

We always knew you had a wild side, Martin.

> On 7 Mar 2019, at 9:41 am, Martin Thomson <mt@lowentropy.net> 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.  

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/

Received on Friday, 8 March 2019 06:06:57 UTC