HTTP/3 frame encodings are unnecessarily difficult to serialize and parse

[ianswett]

Multiple HTTP/3 frames have lengths, but do not require the length to deserialize.

On the serialization side, those require extra work to determine the size before serializing them, which may or may not be easy. SETTINGs is fairly complex because it's a series of varints, so you either need to do a two-pass serialization or write the SETTINGs and then go back and write the length(possibly assuming it's a 2 byte length?).

On the parsing side, extra work is required to verify that the parsed length matches the specified length.

This also wastes a byte or two in a few cases.

I suggest we use the principle that if it's easier to serialize and deserialize without a frame length then the length should be omitted, unless it's expected implementations will want to skip the frame in question, such as extension frames. Extension frames should only omit a length in cases when the length would be misleading(ie: DATA frame that extends to the end of the stream) or the extension is negotiated and skipping over the frame would cause HTTP/3 to not perform correctly.

Related to #2395

[LPardue]

If we want to do this, we should still mandate that all extension frames have a length, so endpoints can easily skip over them

…

On Thu, 31 Jan 2019, 08:42 ianswett ***@***.*** wrote: Multiple HTTP/3 frames have lengths, but do not require the length to deserialize. On the serialization side, those require extra work to determine the size before serializing them, which may or may not be easy. SETTINGs is fairly complex because it's a series of varints, so you either need to do a two-pass serialization or write the SETTINGs and then go back and write the length(possibly assuming it's a 2 byte length?). On the parsing side, extra work is required to verify that the parsed length matches the specified length. This also wastes a byte or two in a few cases. I suggest we use the principle that if it's easier to serialize and deserialize without a frame length then the length should be omitted. Related to #2395 <#2395> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2396>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGRFtSXbUdtdRyi8ayoXbmMiMe6muzujks5vIi3mgaJpZM4abScO> .

[DavidSchinazi]

@LPardue we need to mandate that non-negotiated extension frames have lengths. If you've established that both endpoints support a particular extension, then you can send the corresponding length-less extension frames

[LPardue]

I agree, I misread Ian's final sentence on this issue

[ianswett]

Sorry, I added clarification after originally filing the issue, so you probably read the email and didn't see the updated text.

[MikeBishop]

Discussed in Tokyo; we like the length to be present so that we can know whether we have the entire frame before we begin parsing the frame. We have decided to keep the length field on all frames, even where redundant.