- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 8 Mar 2019 17:06:27 +1100
- To: Martin Thomson <mt@lowentropy.net>
- Cc: ietf-http-wg@w3.org
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