Automatically reset received push promises if push promises havee been disabled.

[carllerche]

Relevant spec:

This setting can be used to disable server push (Section 8.2). An endpoint MUST NOT send a PUSH_PROMISE frame if it receives this parameter set to a value of 0. An endpoint that has both set this parameter to 0 and had it acknowledged MUST treat the receipt of a PUSH_PROMISE frame as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.

The initial value is 1, which indicates that server push is permitted. Any value other than 0 or 1 MUST be treated as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.

So, the issue is that the default value if "enabled", so the server can actually send push promises before the SETTINGS frame has been received.

The behavior should probably be:

• If the SETTINGS frame that disabled push promises has been ACKed, then receiving a push promise results in a connection error of type PROTOCOL_ERROR.
• If the SETTINGS frame that disabled push promises has been sent but not ACKed, received push promises are automatically reset.

[seanmonstar]

Yea, but frankly that's super annoying. A client sends its settings frame the same time it sends the initial request, so a server that receives that and decides to send push promises anyways is just a turd.

The only legitimate case would be if a client decides to send a new settings frame mid-connection to disable push promises from then on, but we have no way of currently allowing a user to do that.

[seanmonstar]

We already return a connection error, as seen by this test: https://github.com/carllerche/h2/blob/master/tests/push_promise.rs#L45

I'd suggest that this definitely isn't 0.1 material.