Re: [#150] Making certain settings mandatory

[Roberto Peon <[e-mail]>]

I think we could, but we'll need to send the settings frame in the future
when we decide that those defaults need changing.

-=R


On Sat, Jun 29, 2013 at 12:47 PM, Jeff Pinner <[e-mail]> wrote:

> 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 <[e-mail]> 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 <[e-mail]>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 <[e-mail]> wrote:
>>>
>>>> Again, what happens when the required settings are not in the frame?
>>>>
>>>>
>>>> On Sat, Jun 29, 2013 at 12:20 PM, Jeff Pinner <[e-mail]>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 <[e-mail]>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 <[e-mail]>wrote:
>>>>>>
>>>>>>> +1 To consistent handling of frames, whatever the rules are.
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jun 27, 2013 at 11:05 AM, Mike Belshe <[e-mail]>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 <
>>>>>>>> [e-mail]> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>