Re: HTTP/2.0 -04 candidate

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

Received on Tuesday, 2 July 2013 16:29:56 UTC