Clients should reject any attempt to change the SETTINGS_ENABLE_PUSH setting to a non-zero value

[alexwlchan]

RFC 7540 section 8.2:

Clients MUST reject any attempt to change the SETTINGS_ENABLE_PUSH setting to a value other than 0 by treating the message as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.

If I’ve read this correctly, “attempt to change” means a SettingsFrame, yes?
If so, we don’t do this yet – indeed, there doesn’t seem to be a way for the h2.settings.Settings object to know if it’s for a client or server.

I’m not sure exactly when the Settings object gets configured – the user can specify the initial_values parameter, so presumably a client could have ENABLE_PUSH = 1 set by this way. The validation can’t occur on the Settings object, but we actually receive the frame, in H2Connection._receive_settings_frame().

That seems sub-optimal – it would be good to keep settings-specific logic in settings.py.

Perhaps we add a validate_received_setting() to mirror _validate_setting(), which is defined in settings.py but called in _receive_settings_frame(). This contains any additional checks for settings that come in via a SettingsFrame.

[Lukasa]

Attempt to change does mean a SettingsFrame, yes. However, it seems like you're getting a bit turned around about setting stuff.

Yes, a client can have ENABLE_PUSH=1 set by the initial_values parameter, but that can only happen for the settings it offers to its peer. Remember that, like with flow control windows, there are always two collections of active settings: those sent by the client to the server, and those sent by the server to the client.

However, all of this is easier than you think because the H2Settings object already gets told whether it's for a client or not. All we need to do to add extra validation is to persist that value on the object, and then extend _validate_setting to take a client parameter that determines whether the entity setting the value is a client or not. This is probably pretty easy, tbh.