Subject: Error behevior of receiving PUSH_PROMISE when SETTINGS_ENABLE_PUSH is 0

From: Shigeki Ohtsu <[email-masked]>
Date: Thu, 09 Jan 2014 10:44:32 +0900

Hi,

There is no description about the behavior of receiving PUSH_PUROMISE when
SETTINGS_ENABLE_PUSH is 0.

As the other errors caused by PUSH_PROMISE, MUST the receiver treat it as
 a connection error of type PROTOCOL_ERROR?

The difference between two cases in receiving PUSH_PROMISE when
SETTINGS_MAX_CONCURRENT_STREAMS is 0 and when SETTINGS_ENABLE_PUSH is 0 is
that the former accepts PUSH_PROMISE whereas the latter does not.
Is this correct?

And I also found no description of the case when a server receive PUSH_PROMISE.
It should be also treated as a connection error. Right?

Regards,

---

From: Roberto Peon <[email-masked]>
Date: Wed, 8 Jan 2014 17:56:23 -0800

>  a connection error of type PROTOCOL_ERROR?
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.

> that the former accepts PUSH_PROMISE whereas the latter does not.

correct.

> 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.
-=R

---

From: Shigeki Ohtsu <[email-masked]>
Date: Thu, 09 Jan 2014 11:33:18 +0900

> 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

Yes, there is a racing condition to synchronize ENABLE_PUSH.
A client needs to choice accept or reset promised streams in that case.

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 10 Jan 2014 10:05:12 -0800

Thanks for picking this up.  I've made some edits that address this:

https://github.com/http2/http2-spec/commit/3f6da66705bfacaf9f325d3b9265d09d4c44fd3e

(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 <[email-masked]> wrote:
>> lower-layer stuff is symmetrical, though it makes little sense at the