Re: HTTP/2.0 -04 candidate

On Tue, Jul 2, 2013 at 9:52 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
> On 2 July 2013 09:44, James M Snell <jasnell@gmail.com> wrote:
>> In other
>> words, we say that PUSH_PROMISE MUST NOT include :host or :scheme
>> and that clients MUST ignore them if they are sent.
>
> I don't like the prohibition because it's too simple.
>
> Say I do have, as Will points out, a forward proxy.  One huge
> advantage that proxy could provide is push for cross-domain resources.
>

The prohibition does not eliminate this possibility, not by any
stretch. Remember, we still also have Content-Location that we can
play with here... and there is plenty of room for experimentation with
other new kinds of response headers that could be used to indicate
that one domain has given another domain permission to push it's
content.

For instance, let's consider your push proxy pushing content for
cross-domain resources...

The proxy receives a GET from the client for domain example.org and
decides that it is going to push content from someother.example.com...
One (quick strawman) approach to allow for this would be something
like:

PUSH_PROMISE
    :path = http://someother.example.com/some-other-content.js
    push-authorization: {auth token of some sort}

When the client receives this, the :scheme and :host still point to
example.org, but because the :path contains a full URL, the client can
easily detect that the proxy is attempting to push content for another
domain. The hypothetical push-authorization header (defined as a
request header for the purposes of push_promise) would include a token
issued by someother.example.com that the client can use to verify that
example.org is allowed to push that content.

Now, this is just a strawman example, but it demonstrates that we can
achieve the cross-domain push while still having the No :host or
:scheme in PUSH_PROMISE restriction.

> Or, say we do provide features for virtual hosting that would allow a
> CDN or aggregated hosting arrangement to become "authoritative" for
> multiple names.
>
> The current text says something like "make sure the server is allowed
> to push".  Which permits both kinds of arrangement.  Reducing the
> mandatory set of headers to just ":path" would be enough, I think.
> Prohibiting the others might be over-rotating.

In general, I have a challenge making statements like "make sure the
server is allowed to push" without defining (or referring to) any
means of actually performing that verification... but ah well...

Perhaps a bit of a compromise... for now, can we say for now that *If*
the PUSH_PROMISE contains a :host and :scheme it SHOULD be the same as
the originating request and say further that a client SHOULD NOT
accept a push with a different :host and :scheme unless it can verify
(via currently unspecified means) that the originating domain has
permission to push that content.

Yes, it's close to the original language but uses SHOULD and SHOULD
NOT to hopefully make things quite a bit stronger. I'm definitely +1
on saying that only :path is required in PUSH_PROMISE tho, and that if
:scheme and :host are omitted, they are inherited from the originating
request.

Does that work better?

Received on Tuesday, 2 July 2013 17:16:22 UTC