Re: HTTP/2.0 -04 candidate

Thinking it through, omitting the host and scheme from a push_promise
makes the most sense for a number of reasons...

Logically, this is *server push*. The server is ultimately determining
where the content comes from. It could just as easily do a GET to some
other domain and push that to the client as if it were actually hosted
locally... the point is, the client doesn't really care. It sends a
single request to A Host, get's N-responses back from that Host. It
ought to be naturally assumed that the pushed content is associated
with the same host the original request was directed to. In other
words, we say that PUSH_PROMISE MUST NOT include :host or :scheme
and that clients MUST ignore them if they are sent.

So.. a client sends...

HEADERS
  + END_STREAM
     :method = GET
     :host = example.org
     :scheme = http
     :path = /foo/bar/baz

The server responds with...

HEADERS
  - END_STREAM
    :status = 200
    content-type: text/html
    content-length: 123

PUSH_PROMISE
    :method = GET
    :path = /foo/images/a.png

PUSH_PROMISE
    :method = GET
    :path = /foo/images/b.png

DATA
  + END_STREAM

The :host and :scheme for the two promised implied GETS are
example.org and http. If the server wishes to indicate that the
content actually lives somewhere else, it can include a
Content-Location header in the HEADERS of the two pushed streams.

This approach feels natural and simple, without introducing the need
for same-origin complexity.

- James

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

Received on Tuesday, 2 July 2013 16:45:03 UTC