- From: Patrick McManus <pmcmanus@mozilla.com>
- Date: Wed, 16 Mar 2016 14:35:56 -0400
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Patrick McManus <pmcmanus@mozilla.com>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAOdDvNoSUd4TNjfJOUSrREQvdBG1rxufTpE0gawwmE5aT_8V_w@mail.gmail.com>
On Mon, Mar 14, 2016 at 6:59 PM, Martin Thomson <martin.thomson@gmail.com> wrote: > > It's a small concern, because I think that the risk is small in > comparison to the potential gain, but I don't think that this is > something that we can reasonably ignore. [until we adopt a draft this is all just kick-the-ball-around stuff] fwiw, there is a spectrum of ways to interpret the 7540 rules that a declarative origin frame could help with. in 7540 coalescing Firefox goes a little towards the aggressive side in order to enable coalescing on a couple of content providers that want coalescing but don't always advertise consistent DNS views. This has caught a couple other providers by surprise who saw coalescing but did not expect it in an edge case (I get to explain 421 to them :)) - an origin extension that opts in arbitrary origins provides a more deterministic implementation. I would want to address the change with strong text to make this clear (something I think, only in retrospect, that 7540 could have done stronger around coalescing rules there.) but as a practical matter the internet is moving away from addressing defining content and this just rides that wave. and sure, content-centric or named-data networking lies somewhere on that road. But its too far away to see clearly :) Names are what identify content and signatures are what makes you believe it. The notion of DNS resolution and IP routes being directly tied to this is already long gone and folks depending on that are probably in grave peril already (i.e. http://). Which is why we already don't rely on it in https://. And if you are faced with a certificate compromise, relying on routing to save you is pretty weak solace. When I click on my search provider button maybe I am routed to searchProvider's data center.. but maybe I'm routed to a CDN, or maybe dynamically load shifted to a fail over CDN the way CDNI talks about.. perhaps it changes every 300 seconds. maybe I'm served out of a cache (perhaps local, perhaps remote) or directed to an alternate service.. maybe my route is hijacked L4 style by a transparent device that lies about the addressing. Perhaps I'm behind a nat. Or two. Or three. Or have had my DNS spoofed via race condition. Or routed via an onion network or plain old vpn. In all of those cases the decision on whether or not to use the content is independent of addressing and routing - a declarative origin frame isn't moving into uncharted territory. Those addresses and routes are just the ephemeral glue we use to get you to the content you want - the content doesn't inherently possess addresses or routes.. if another set of addresses and routes delivers the same verifiable content in a better way thats a good thing and loosening the implicit dependence on DNS and IP is also good thing. -Patrick
Received on Wednesday, 16 March 2016 18:36:23 UTC