Re: [#153] PUSH_PROMISE headers

+1

At least for the first implementation draft I would suggest we heed James'
suggestion and restrict the headers inside the pushed header block to those
that would have been sent in the request.

If we find later that we *really really* need to add response headers to
the pushed header block then we can reevaluate. Or perhaps after some
implementation experience we figure out that with some thought into
selection of the pushed headers there is not a compelling enough reason to
add the extra complexity.


On Sat, Jun 29, 2013 at 7:27 AM, James M Snell <jasnell@gmail.com> wrote:

>
> On Jun 29, 2013 1:03 AM, "Amos Jeffries" <squid3@treenet.co.nz> wrote:
> >
> [ snip ]
>
> >
> > The above example is a good one.
> >
> > The cache will store the pushed response under:
> >   hash(URL)+hash(Vary:"image/jpeg")
> >
> > When looking up future HIT the cache for this client on explicit-GET it
> will look up
> >   hash(URL)+hash(Vary:"text/html, image/jpeg, image/gif")
> >
> > I assume you can spot the difference.
> >
>
> I didn't miss that. Pushed resources and content negotiation used together
> have rather, um, "interesting" complications. However, those don't change
> the request headers in the push promise and response headers in the HEADERS
> question which is what I was addressing.
>
> - James
>