Re: [#150] Making certain settings mandatory

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