Subject: [quicwg/base-drafts] Reorder HTTP frame fields to put Type first (#1351)

From: Dirkjan Ochtman <[email-masked]>
Date: Fri, 11 May 2018 06:36:28 -0700

This would make parsing easier to deal with. I don't think there are adverse effects?

I'm proposing standardizing this:

```
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+
   |    Type (8)   |   Flags (8)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Length (i)                        ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Frame Payload (*)     ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```    0                   1                   2                   3

instead of this:

```
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Length (i)                        ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type (8)   |   Flags (8)   |       Frame Payload (*)     ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```

-- 
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/1351

---

From: Dmitri Tikhonov <[email-masked]>
Date: Fri, 11 May 2018 06:51:55 -0700

Why is one easier than the other?

-- 
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/1351#issuecomment-388369891

---

From: Dirkjan Ochtman <[email-masked]>
Date: Fri, 11 May 2018 07:03:08 -0700

With type first, you can directly dispatch to a type-specific parser. Additionally, it would be more similar to how QUIC packets work (header type in the first bit) and how QUIC frames work (type in the first byte).

-- 
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/1351#issuecomment-388373107

---

From: Dmitri Tikhonov <[email-masked]>
Date: Fri, 11 May 2018 07:05:48 -0700

Yes, but you still need to parse the length -- to skip unknown frames.  Even with a dispatch table, it is better to parse the length in one place rather than in each type-specific function.

-- 
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/1351#issuecomment-388373787

---

From: Dirkjan Ochtman <[email-masked]>
Date: Fri, 11 May 2018 07:09:44 -0700

Why is that better? I don't think I necessarily agree. Having to pass the length to the type-specific parser makes the interface different from the one in other places, as explained, and more tightly bound.

Additionally, I prefer having variable-sized fields after types of statically known size.

-- 
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/1351#issuecomment-388374835

---

From: Dmitri Tikhonov <[email-masked]>
Date: Fri, 11 May 2018 07:16:15 -0700

> Why is that better?

Less code duplication.

I prefer fixed-width fields first, too.  This preference, however, is not a valid _technical_ argument (the "making parsing easier to deal with" part in you original post).  If we want to argue for this change on the merits of its prettiness, we should frame (ha! get it?) the argument accordingly.

-- 
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/1351#issuecomment-388376718

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 11 May 2018 07:26:37 -0700

The frame layout is close to HTTP/2. However it IS already different
because it strips the Stream ID.

There is unlikely to be much reuse between h2 parsers and hq frame parsers.

On Fri, 11 May 2018, 15:09 Dirkjan Ochtman, <[email-masked]>
wrote:

> Why is that better? I don't think I necessarily agree. Having to pass the
> length to the type-specific parser makes the interface different from the
> one in other places, as explained, and more tightly bound.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/1351#issuecomment-388374835>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AGRFtVTt8JYOXFx2e4vdez6j9Kji8OnUks5txZungaJpZM4T7eOr>
> .
>

-- 
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/1351#issuecomment-388379729

---

From: Mike Bishop <[email-masked]>
Date: Fri, 11 May 2018 11:18:11 -0700

The existing order is because it started with what was in HTTP/2, but we've already established consensus that similarity to HTTP/2 isn't a sufficient reason to keep any non-functional aspect.

I'm inclined to think that reading the length first, then knowing how much data to pass to your type-specific parser would be the most efficient.  The varint Length means that frames can be very large (DATA frames, especially), so you don't want to wait until you have the entire frame to start processing it, but knowing when to stop passing data to the parser and dispatch a new frame seems worthwhile nonetheless.

I don't have hands on an implementation of this, though, so if there's consensus that one is easier to parse than the other, I'm fine either way.

-- 
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/1351#issuecomment-388444699

---

From: Martin Thomson <[email-masked]>
Date: Fri, 11 May 2018 17:36:29 -0700

Having implemented this, I read the header in a single go.  So order makes no difference (at least to me).  That suggests that there is no value in reordering, other than the aesthetic ones, on which we might reasonably disgree.  That suggests no change to me as well.

-- 
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/1351#issuecomment-388517234

---

From: Dirkjan Ochtman <[email-masked]>
Date: Sat, 12 May 2018 04:33:52 -0700

What about the consistency (with packet header types and frame types)?

-- 
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/1351#issuecomment-388548932