Re: HTTP/2.0 -04 candidate

On Tue, 2 Jul 2013, James M Snell 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}
> > 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.

Um, this is getting complicated with no security value. The :path
header now is more complex to parse and hence may encounter more
errors.

Received on Tuesday, 2 July 2013 17:40:23 UTC