Re: [#150] Making certain settings mandatory

So devil's advocate -- why make the mandatory during Upgrade?

If the client is upgrading to HTTP/2.0 and doesn't send them, why can't we
just assume that the client has accepted the default values?


On Sat, Jun 29, 2013 at 12:41 PM, Roberto Peon <grmocg@gmail.com> wrote:

> This is why it seems like this doesn't make sense to me- we're proposing
> to tear down the connection for an error which neither causes corruption,
> nor causes state mismatch.
>
> This also does nothing to reduce complexity. We've moved a conditional
> from the startup, which is already special in the first place (the magic
> string) to elsewhere, while requiring more bytes on the wire and more ways
> to randomly/accidentally tear down the connection.
> This requirement also does nothing to simplify the parsing of the settings
> frame, as it might contain other settings, especially in the future.
>
> -=R
>
>
> On Sat, Jun 29, 2013 at 12:31 PM, Jeff Pinner <jpinner@twitter.com> wrote:
>
>> If it's a MUST and the required settings aren't there you'd have to close
>> down the connection, same way you would for any other badly formatted frame
>> that you couldn't interpret.
>>
>>
>> On Sat, Jun 29, 2013 at 12:30 PM, Roberto Peon <grmocg@gmail.com> wrote:
>>
>>> Again, what happens when the required settings are not in the frame?
>>>
>>>
>>> On Sat, Jun 29, 2013 at 12:20 PM, Jeff Pinner <jpinner@twitter.com>wrote:
>>>
>>>> If you don't want them to be mandatory then don't make them mandatory
>>>> as part of the Upgrade mechanism and rely on the defaults if you choose to
>>>> upgrade without including them.
>>>>
>>>> Consistency :)
>>>>
>>>>
>>>> On Sat, Jun 29, 2013 at 12:16 PM, Roberto Peon <grmocg@gmail.com>wrote:
>>>>
>>>>> Ug. Slippery slope.
>>>>> I'm happy to say the settings frame is mandatory, you SHOULD send
>>>>> settings you care about in the initial settings frame, and otherwise you
>>>>> get what you get.
>>>>>
>>>>> This is less complicated. What would be the result of not having the
>>>>> mandatory fields in the settings frame as proposed above? If it isn't
>>>>> 'close down the connection', the requirement is useless.
>>>>>
>>>>> -=R
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Jun 29, 2013 at 12:03 PM, Jeff Pinner <jpinner@twitter.com>wrote:
>>>>>
>>>>>> +1 To consistent handling of frames, whatever the rules are.
>>>>>>
>>>>>>
>>>>>> On Thu, Jun 27, 2013 at 11:05 AM, Mike Belshe <mike@belshe.com>wrote:
>>>>>>
>>>>>>> I believe the bytes are completely inconsequential.
>>>>>>>
>>>>>>> My goal with this was to make it so there is only one set of rules
>>>>>>> for SETTINGS frames.  Currently, there is the "oh this is the first
>>>>>>> settings frame rules".
>>>>>>>
>>>>>>> This is not going to have impact on performance, but removing edge
>>>>>>> cases is desirable to me.
>>>>>>>
>>>>>>> Mike
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jun 27, 2013 at 10:27 AM, Martin Thomson <
>>>>>>> martin.thomson@gmail.com> wrote:
>>>>>>>
>>>>>>>> This pull request proposes to make two settings mandatory in every
>>>>>>>> SETTINGS frame: SETTINGS_MAX_CONCURRENT_STREAMS and
>>>>>>>> SETTINGS_INITIAL_WINDOW_SIZE.
>>>>>>>>
>>>>>>>> https://github.com/http2/http2-spec/pull/150
>>>>>>>>
>>>>>>>> Gabriel's proposal for an HTTP/1.1 header for carrying settings in
>>>>>>>> the
>>>>>>>> Upgrade made these mandatory only at that point, which didn't cover
>>>>>>>> the TLS handshake, or just starting from prior knowledge.
>>>>>>>>
>>>>>>>> Two questions:
>>>>>>>>  - Do we want to make any settings mandatory, or are defaults
>>>>>>>> acceptable?
>>>>>>>>  - Is this the right trade-off? Or are the 16 bytes on subsequent
>>>>>>>> SETTINGS frames completely intolerable.
>>>>>>>>
>>>>>>>> Note that if we make these settings mandatory, there might be other
>>>>>>>> settings in the future that will also be mandatory; e.g., the
>>>>>>>> compression context size.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>