Re: [#153] PUSH_PROMISE headers

+1


On Tue, Jul 2, 2013 at 4:13 PM, Roberto Peon <grmocg@gmail.com> wrote:

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