Re: [#153] PUSH_PROMISE headers

That problem would be assuming that the proxy doesn't correctly translate
when generating its push, should it do so, but yes.
Being explicit for request headers for push has (or should have) a low cost
given the compression stuff, and makes life much more simple in general
otherwise.
-=R


On Tue, Jul 2, 2013 at 2:42 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:

> On 3/07/2013 8:24 a.m., Mike Bishop wrote:
>
>> Did we have consensus here on whether PUSH_PROMISE in the Implementation
>> Draft contains *all* request headers or simply the ones that have changed
>> from the original request?
>>
>> The more I think about it, I'm inclined to say "all" since the server can
>> drop any headers it knows it won't be looking at if it wants, and headers
>> that are the same will just get compressed out after they've been pushed
>> back once.
>>
>
> Except that they are being sent over the response side of the connection
> so they are affecting the server send context and client receive context.
> They are also likely to die again quickly under the relatively large bunch
> of response HEADERS blocks which are following - both the main response and
> the pushed ones.
>
> I'm sightly in favour of "all" as well despite that problem because when
> sending over multiple hops the request headers may be altered. The server
> omiting header Foo because a proxy delivered Foo:hello when the client sent
> Foo:bar will cause big potential issues with both security validation and
> caching. Ensuring those functionalities work reliably outweighs some
> sub-optimal performance IMO.
>
> Amos
>
>
>