- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 13 Jul 2023 17:20:05 +0200
- To: Watson Ladd <watsonbladd@gmail.com>
- Cc: Benjamin Schwartz <ietf@bemasc.net>, ietf-http-wg@w3.org
Hi, On Tue, Jul 11, 2023 at 04:00:59PM -0700, Watson Ladd wrote: > Could you say more about the usecase? I looked over the doc briefly, > but am still confused. I've seen comparable mechanisms used 20 years ago (they were archaic by then, running over HTTP/1) to make sure no single connection could be initiated from within a sacrifiable DMZ. The idea was that the client- facing gateway was isolated alone and if it got intruded, the attacker couldn't go further. We at haproxy have got some demands over the last ~8 years to do something similar to help developers test their code running on their PC while being part of a larger application, again with the connection initiated from the dev's PC. Initially I used to say "it will be easier with H2" but various technical limitations still served as (valid) excuses for postponing. Now they're apparently all gone and we expect to make progress on this. Another (less common) use case that was expressed to us over the years was the ease of self-hosting when your ISP delivers you a dynamic address. You just need to have your internal gateway that connects to an external one that can be shared and handled that way, a bit more conveniently than with a VPN. Also it can be easier to support multi-path this way (choose any working connection to send the request). A more recent case that came to our mind was the ease of registering HTTP components against an edge URL dispatcher for short-lived services. I'm sure there are other use cases, but we'll likely discover them over time. Hoping this helps, Willy
Received on Thursday, 13 July 2023 15:20:13 UTC