Re: HTTP/2.0 -04 candidate

There are other reasons to have different host names other than just name
sharding to increase parallelism. I do hope that they will be reduced in a
HTTP/2 world, but I expect them to still exist and it seems reasonable to
try to share connections where advantageous to do so.

Moreover, consider HTTP forward proxies. Browsers today can explicitly
configure them, or rely on PAC scripts to specify such proxies. These
proxies can serve resources for different origins over the same proxy
connection (although they cannot be multiplexed in HTTP/1.X). I don't see
why we would want to remove that capability in HTTP/2.


On Tue, Jul 2, 2013 at 9:29 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
>
>
>