Re: HTTP/2.0 -04 candidate

As is done with SPDY today:
If the cert matches, and the DNS resolution for the hostname includes the
IP to which a preexisting connection is connected, then that connection can
be shared.

In many cases, different hosts are used as a workaround for the max
concurrency limit in http/1.x. Right now this is suboptimal for http/2, as
it must do a DNS lookup to determine if it can share the connection. Things
begin to change from suboptimal to bad when you force http/2 to make as
many connections as http/1 (all because the site was smart and did domain
sharding to optimize http/1.x traffic).

Right now there is no way for the client to share a connection between
hosts where the DNS resolutions don't overlap.

None of this changes the same origin policies at the HTTP semantic layers--
this is purely a session layer thing.

-=R
 On Jul 2, 2013 9:31 AM, "Sam Pullara" <spullara@gmail.com> wrote:

> On Jul 2, 2013, at 6:21 AM, Albert Lunde <atlunde@panix.com> wrote:
> > On 7/2/2013 12:22 AM, Sam Pullara wrote:
> >> I suggest that you limit to same origin and remove the :schema and the
> >> :host. It is quite probable that a different host, even if could be
> >> served from the same IP address, actually resolves to a different IP
> >> address when the client resolves it. Even the same :host could resolve
> >> to a different IP address.
> >
> > A case where this could become less obvious might be a server or cluster
> of servers offering a number of name-based virtual hosts. It's fairly
> common for a virtual host to have two or four aliases.
> >
> > Also, there may be shared resources the server knows about that aren't
> obviously related to a client's view of  "origins", like a host name used
> to serve particular media types or groups of content, such as shared
> styles, images, or sounds.
>
> How would the client determine that the server is allowed to serve
> resources from another origin that doesn't resolve to the same IP address?
> Serving assets like JavaScript, Flash objects, Java applets, etc. from a
> particular origin has security implications for the client. Further, if
> this server can serve it, is there any reason for another origin to be
> used? Different origins were used in the past for a wide variety of reasons
> but the most obvious one is that the main origin doesn't have the asset,
> secondarily to increase concurrency in HTTP/1.1. HTTP/2.0  should get rid
> of the idea that you need a bunch of different host names to optimally
> serve your pages that have a lot of resources on them since you only need
> one connection and they can be muxed together.
>
> Sam
>
>
>