Possible detection via http2 settings frame order

[gotsteez]

I overlooked the fact that the http2 settings will technically be ordered with InitialWindowSize and HeaderTableSize always being the last two header frames sent. No site is detecting via http2 setting order at the moment, so it is not problem, but the fix is also pretty easy. In order to fix this error, there needs to be an underlying API change detailed below. What are everyone's opinions on this?

Code that creates error:

	setMaxHeader := false
	if t.Settings != nil {
		for _, setting := range t.Settings {
			if setting.ID == SettingMaxHeaderListSize {
				setMaxHeader = true
			}
			if setting.ID == SettingHeaderTableSize || setting.ID == SettingInitialWindowSize {
				return nil, errSettingsIncludeIllegalSettings
			}
			initialSettings = append(initialSettings, setting)
		}
	}
	if t.InitialWindowSize != 0 {
		initialSettings = append(initialSettings, Setting{ID: SettingInitialWindowSize, Val: t.InitialWindowSize})
	} else {
		initialSettings = append(initialSettings, Setting{ID: SettingInitialWindowSize, Val: transportDefaultStreamFlow})
	}
	if t.HeaderTableSize != 0 {
		initialSettings = append(initialSettings, Setting{ID: SettingHeaderTableSize, Val: t.HeaderTableSize})
	} else {
		initialSettings = append(initialSettings, Setting{ID: SettingHeaderTableSize, Val: initialHeaderTableSize})
	}
	if max := t.maxHeaderListSize(); max != 0 && !setMaxHeader {
		initialSettings = append(initialSettings, Setting{ID: SettingMaxHeaderListSize, Val: max})
	}

Proposed Fix:

• Have the http2 Transport Settings field changed from

	// Settings should not include InitialWindowSize or HeaderTableSize, set that in Transport
	Settings          []Setting
	InitialWindowSize uint32 // if nil, will use global initialWindowSize
	HeaderTableSize   uint32 // if nil, will use global initialHeaderTableSize

to

    Settings map[SettingID]uint32

This would require everyone using the library to change their code, but since this isn't a pressing issue that seems like unnecessary work.

[bogdanfinn]

@zMrKrabz i created a branch on my fork adressing this issue and taking your proposed fix into account.

my issue was next to the order issue that my fhttp client always sends MAX_FRAME_SIZE and ENABLE_PUSH. My browser did not do it actually. therefore i need another possibility to define the settings which are actually sent next to the order of the settings.

ranging over Settings map[SettingID]uint32 might fuck up the order because of the random iteration over a map. but more to this can be found in my changeset.

feedback is appreciated :-)