Re: draft-nottingham-httpbis-origin-frame

A possibly related edge case worth considering; suppose server1.example.com
is provided by a global CDN, and server2.example.com only exists in NZ, and
the browser is in the UK.

What would be the desired behaviour if the initial connection is made to
server2.example.com (NZ), which advertises it's also an origin for
server1.example.com (which it is, although the closest CDN endpoint to the
browser is in the UK)?

Phil

On Wed, Mar 16, 2016 at 6:35 PM, Patrick McManus <pmcmanus@mozilla.com>
wrote:

>
> 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
>
>