Re: HTTP/2.0 -04 candidate

I don't understand why this proposal is an improvement.


On Tue, Jul 2, 2013 at 10:15 AM, James M Snell <jasnell@gmail.com> wrote:

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