Re: [quicwg/base-drafts] HTTP SETTINGS: define setting content encoding (#1556)

[Mike Bishop <[e-mail]>]

@afrind, that's an interesting point.  Could you split that out into a separate issue?

The current boolean encoding is intended to save bytes in the case of turning something on/off and not needing to convey any other data (e.g. "I support extension Foo").  If you don't send anything, the default case, it's false; it takes the minimum possible length to send true.  Because HQ doesn't allow modifying settings after the initial setup, we don't need an affordance for turning something that was true back to false.  In HTTP/2, you got 32 bytes regardless of how much or little you needed to convey, so settings of this sort use 0/1 and make other value invalid, or they use 0/non-zero.  However, most extensions to HTTP/2 so far have defined non-critical frames that didn't need a setting.

I'm not opposed to saying the payload of the integer settings isn't a varint, but it seems like that introduces additional complexity to deal with oddly-sized integers.  Is that a noticeably different level of complexity from having to check that the varint is the size claimed by the setting?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1556#issuecomment-408522332