W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

Re: Error behevior of receiving PUSH_PROMISE when SETTINGS_ENABLE_PUSH is 0

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 10 Jan 2014 10:05:12 -0800
Message-ID: <CABkgnnWZzgu_bX_hfLtni=Pm8MNK+X2MXTK7NJZHY0Mt96=t_A@mail.gmail.com>
To: Shigeki Ohtsu <ohtsu@iij.ad.jp>
Cc: Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Thanks for picking this up.  I've made some edits that address this:


(If we keep this up, we'll have a pretty solidly bulletproof spec by
the end of this.)

As always pull requests or other forms of feedback appreciated.

On 8 January 2014 18:33, Shigeki Ohtsu <ohtsu@iij.ad.jp> wrote:
>> hmm, surprising that it wouldn't be defined, but I haven't checked lately.
>> a connection-error is reasonable, but if the value of ENABLE_PUSH is
>> changing, you'll want to ensure that you've received the ACK for the
>> appropriate setting before treating it as an error.
> Yes, there is a racing condition to synchronize ENABLE_PUSH.
> A client needs to choice accept or reset promised streams in that case.
>>     And I also found no description of the case when a server receive
>>     It should be also treated as a connection error. Right?
>> There is nothing wrong with a server receiving a PUSH_PROMISE since the
>> lower-layer stuff is symmetrical, though it makes little sense at the
>> HTTP layer, which should probably treat it as an error of some kind.
> Yes, in framing layer PUSH_PROMISE is defined with the word of an endpoint
>  neither a server nor a client.
> The terms of a server and a client in the sepc are defined as the condition
>  in which TCP connection is initiated so there can be an another world where
>  a non-HTTP request is sent from a server to a client.
Received on Friday, 10 January 2014 18:05:40 UTC

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