Re: [#150] Making certain settings mandatory

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