Re: [#150] Making certain settings mandatory

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.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>