W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2019

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

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

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2019 06:06:58 UTC