HTTP SETTINGS: why reuse codepoint 0x3?

[dtikhonov]

From the spec:

   SETTINGS_NUM_PLACEHOLDERS (0x3):  This value SHOULD be non-zero.  The
      default value is 16.

   SETTINGS_MAX_HEADER_LIST_SIZE (0x6):  The default value is unlimited.

It seems inconsistent to reuse 0x3 while forbidding other setting IDs from RFC 7540. SETTINGS_NUM_PLACEHOLDERS is not the same as SETTINGS_MAX_CONCURRENT_STREAMS.

[MikeBishop]

Hand-wavy similarity. It's a limit on the number of a given resource the peer is allowed to consume. I frankly don't care one way or the other -- if having the reuse causes more issues for anyone's implementation than changing the codepoint does, I'm happy to move it.

[MikeBishop]

Note that it would have needed a new codepoint if the HTTP WG wanted to adopt placeholders for HTTP/2, but that got the thumbs-down in Montreal.

[dtikhonov]

We explicitly forbid other HTTP settings because (presumably?) we want to catch bugs. By reusing 0x3, we allow for a potential bug when one side uses HTTP2 semantics -- likely due to some code reuse -- instead of HQ.

There are two consistent choices: either use another value instead of 0x3, or renumber HQ settings and not care about forbidding HTTP2 setting values.

[MikeBishop]

Not so much bug-catching as to simplify life for people with shared code-bases. But sure, I don't have a problem with moving it. That would be a breaking change, though, so I'll save it for post-16.