Repository navigation
Clients should reject any attempt to change the SETTINGS_ENABLE_PUSH setting to a non-zero value #316
Description
Activity
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=1set by theinitial_valuesparameter, 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
H2Settingsobject 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_settingto take aclientparameter that determines whether the entity setting the value is a client or not. This is probably pretty easy, tbh.
RFC 7540 section 8.2:
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.Settingsobject to know if it’s for a client or server.I’m not sure exactly when the
Settingsobject gets configured – the user can specify theinitial_valuesparameter, so presumably a client could haveENABLE_PUSH = 1set by this way. The validation can’t occur on theSettingsobject, but we actually receive the frame, inH2Connection._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 insettings.pybut called in_receive_settings_frame(). This contains any additional checks for settings that come in via aSettingsFrame.