W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: [#153] PUSH_PROMISE headers

From: (wrong string) 陈智昌 <willchan@chromium.org>
Date: Tue, 2 Jul 2013 16:31:46 -0700
Message-ID: <CAA4WUYgqu6A+BQ7rq-o0ofcV6FegXV3jp=fF-MSZT+y_M-izYQ@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
+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
>>
>>
>>
>
Received on Tuesday, 2 July 2013 23:32:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC