Subject: [#150] Making certain settings mandatory

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Jun 2013 10:27:26 -0700

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.

---

From: Mike Belshe <[email-masked]>
Date: Thu, 27 Jun 2013 11:05:50 -0700

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

---

From: Jeff Pinner <[email-masked]>
Date: Sat, 29 Jun 2013 12:03:31 -0700

+1 To consistent handling of frames, whatever the rules are.

On Thu, Jun 27, 2013 at 11:05 AM, Mike Belshe <[email-masked]> wrote:

> 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 <[email-masked]
> > wrote:
>

---

From: Roberto Peon <[email-masked]>
Date: Sat, 29 Jun 2013 12:16:20 -0700

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 <[email-masked]> wrote:

>> On Thu, Jun 27, 2013 at 10:27 AM, Martin Thomson <
>> [email-masked]> wrote:
>>

---

From: Jeff Pinner <[email-masked]>
Date: Sat, 29 Jun 2013 12:20:22 -0700

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 :)

---

From: Roberto Peon <[email-masked]>
Date: Sat, 29 Jun 2013 12:30:54 -0700

Again, what happens when the required settings are not in the frame?

On Sat, Jun 29, 2013 at 12:20 PM, Jeff Pinner <[email-masked]> wrote:

>> 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.
>>
>> On Sat, Jun 29, 2013 at 12:03 PM, Jeff Pinner <[email-masked]>wrote:
>>
>>>> This is not going to have impact on performance, but removing edge
>>>> cases is desirable to me.
>>>>
>>>> Mike
>>>>
>>>>
>>>>

---

From: Jeff Pinner <[email-masked]>
Date: Sat, 29 Jun 2013 12:31:58 -0700

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.

---

From: Roberto Peon <[email-masked]>
Date: Sat, 29 Jun 2013 12:41:15 -0700

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 <[email-masked]> wrote:

>> On Sat, Jun 29, 2013 at 12:20 PM, Jeff Pinner <[email-masked]>wrote:
>>
>>>>>> 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".
>>>>>>

---

From: Jeff Pinner <[email-masked]>
Date: Sat, 29 Jun 2013 12:47:45 -0700

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 <[email-masked]> 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.
>>>> 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
>>>> On Sat, Jun 29, 2013 at 12:16 PM, Roberto Peon <[email-masked]>wrote:
>>>>
>>>>> Ug. Slippery slope.
>>>>>> On Thu, Jun 27, 2013 at 11:05 AM, Mike Belshe <[email-masked]>wrote:
>>>>>>

---

From: Roberto Peon <[email-masked]>
Date: Sat, 29 Jun 2013 13:06:41 -0700

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 <[email-masked]> wrote:

>> 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 <[email-masked]>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.
>>>
>>>

---

From: Eliot Lear <[email-masked]>
Date: Sat, 29 Jun 2013 22:47:54 +0200

On 6/29/13 9:47 PM, Jeff Pinner wrote:
> 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?
>

Because defaults can NEVER be changed.  Sometimes it's better to not
ever have them.

---

From: Jeff Pinner <[email-masked]>
Date: Sun, 30 Jun 2013 12:13:18 -0700

Here the initial values CAN be changed by a client sending the header
during the upgrade process.

The question is if sending certain settings should be mandatory.

Are you proposing we remove all default values and require that they all be
explicitly negotiated?

On Sat, Jun 29, 2013 at 1:47 PM, Eliot Lear <[email-masked]> wrote:

>  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?
>
>
> Because defaults can NEVER be changed.  Sometimes it's better to not ever
> have them.
>

---

From: Eliot Lear <[email-masked]>
Date: Sun, 30 Jun 2013 22:13:28 +0200

On 6/30/13 9:13 PM, Jeff Pinner wrote:
> Are you proposing we remove all default values and require that they
> all be explicitly negotiated?

Not yet.  Truly I was also playing devil's advocate.  Right now simple
ask the question of what happens when you want to change them?  Also, I
wold suggest that if you do have default values you may wish to sort
them very late in the standardization process.

Eliot